a Es un sistema que permite la toma de decisiones colectivas a través de código, sin depender de las jerarquías organizativas tradicionales como los consejos de administración, los CEOs o los CTOs. Desarrollado en una blockchain. DAO (Decentralized Autonomous Organization) smart contracts En su núcleo, un DAO permite a los participantes , de , y de una manera transparente y verificable.El poder de voto suele derivarse de de los participantes, donde cada token representa una unidad de peso de voto. propose vote execute decisions tokens A typical on-chain DAO is composed of three main smart contracts: 
 
 
 
 Contrato de token: Define el token de gobernanza y rastrea el poder de voto. Contrato del gobernador: Gestiona las propuestas y la lógica de votación: quién puede proponer, cómo se cuentan los votos, los requisitos de quórum y los resultados de la propuesta. Actua como una capa de seguridad mediante la aplicación de un retraso entre la aprobación de la propuesta y la ejecución, dando a los participantes tiempo para reaccionar a las decisiones potencialmente perjudiciales. El ciclo de vida de una propuesta es simple pero poderoso: una propuesta se presenta al , los votos se recogen en base a la propiedad del token, y una vez que la propuesta es aprobada, se envía a la Si la propuesta falla, es simplemente descartada. Governor Timelock En esta serie de artículos, construiremos un DAO desde el fondo usando En esta parte ( , nos centraremos en escribir, desplegar y probar el Lo que llamaremos Este token se utilizará más tarde para permitir la votación en cadena y la toma de decisiones en el DAO. OpenZeppelin Part 1) governance token GovernanceToken abiertas El código token Sin más, aquí está el código: // SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import {ERC20Permit} from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol";
import {ERC20Votes} from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Votes.sol";
import {Ownable} from "@openzeppelin/contracts/access/Ownable.sol";
import {Nonces} from "@openzeppelin/contracts/utils/Nonces.sol";

contract GovernanceToken is ERC20, ERC20Permit, ERC20Votes, Ownable {
    constructor()
        ERC20("GovernanceToken", "MGT")
        ERC20Permit("GovernanceToken")
        Ownable(msg.sender)
    {
        _mint(msg.sender, 1_000_000 * 10 ** decimals());
    }

    // Optional: Add controlled minting
    function mint(address to, uint256 amount) external {
        require(msg.sender == owner(), "Only owner can mint");
        _mint(to, amount);
    }

    // ── Conflict resolution ──

    // Both ERC20 and ERC20Votes define _update
    function _update(address from, address to, uint256 amount)
        internal
        override(ERC20, ERC20Votes)
    {
        super._update(from, to, amount);
    }

    // Both ERC20Permit and Nonces define nonces()
    function nonces(address owner)
        public
        view
        override(ERC20Permit, Nonces)
        returns (uint256)
    {
        return super.nonces(owner);
    }
}
 En comparación con un token ERC20 tradicional, integra dos módulos OpenZeppelin adicionales: y . GovernanceToken ERC20Permit ERC20Votes 
 
 ERC20Votes añade funcionalidad específica de gobernanza, más notablemente getPastVotes(account, blockNumber). Esta función devuelve el poder de voto de una cuenta en un bloque específico, en lugar de su saldo actual. En un contexto DAO, este mecanismo instantáneo es crítico: el poder de voto se fija en el momento en que se crea una propuesta, impidiendo a los usuarios manipular los votos mediante la compra o transferencia de tokens después del hecho. 
 
 ERC20Permit permite la aprobación sin gas a través de firmas (EIP-2612), lo que permite a los usuarios delegar o aprobar el poder de voto sin enviar una transacción en cadena. La lógica más importante reside en la , que inicia todos los módulos heredados y miente un millón de tokens de gobernanza al desarrollador. función, limitada al titular del contrato, para permitir la emisión controlada de tokens después de la implementación (útil para pruebas o futuras decisiones de gobernanza). constructor mint Por último, dos funciones - y Esto es necesario porque están definidos en múltiples contratos parentales. Las overrides simplemente delegan la ejecución a , asegurando que todos los comportamientos heredados se componen correctamente y que los conflictos de herencia del compilador se resuelvan limpiamente. _update nonces super Construyendo el token Para construir nuestro token de gobernanza, usaremos , un kit de herramientas de desarrollo Ethereum rápido y moderno. Los pasos siguientes asumen un entorno Linux, pero el flujo de trabajo es similar en macOS. Foundry Comenzamos por instalar Foundry usando el guión de instalación oficial: curl -L https://foundry.paradigm.xyz | bash
 Después de la instalación, el script nos instruye a actualizar nuestro entorno de shell e instalar los binarios de Foundry: source ~/.bashrc   # path may vary depending on your system
foundryup
 Esto instala la cadena de herramientas completa de Foundry: (Construcción y pruebas) (Interacciones de la CLI) (nodo local) y (en el caso de Repl. forge cast anvil chisel A continuación, iniciamos un nuevo proyecto de Foundry en un directorio vacío: mkdir DAO
cd DAO
forge init
 Esto genera un esquema de proyecto completo, incluyendo , de , y Por defecto, Foundry crea un ejemplo Como sólo queremos la estructura del proyecto, podemos eliminar de forma segura estos archivos de ejemplo y reemplazarlos con nuestros propios contratos. src/ script/ test/ Contador Por el momento, añadimos nuestro token de gobernanza bajo : src/ src/
└── GovernanceToken.sol
 (que contiene el del contrato definido en el apartado anterior.) GovernanceToken Debido a que nuestro token depende de los módulos de OpenZeppelin, debemos instalar la biblioteca de contratos de OpenZeppelin: forge install OpenZeppelin/openzeppelin-contracts
 Este comando vende OpenZeppelin en la Directorios y hace sus contratos disponibles para la importación dentro de nuestro proyecto. lib/ Por último, compilamos el proyecto: forge build
 Si todo está configurado correctamente, la compilación se completa con éxito y genera una Esta carpeta contiene los artefactos compilados (ABIs y bytecode) para así como todas las dependencias heredadas de OpenZeppelin. out/ GovernanceToken En este punto, nuestro token de gobernanza está completamente compilado y listo para ser desplegado y probado, pasos que cubriremos en las siguientes secciones. Desarrollar el token Con el token de gobernanza compilado, ahora podemos implementarlo en una blockchain local. . deployment scripts Comenzamos creando un script de implementación Bajo la Dirección : DeployGovernanceToken.s.sol script/ // SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import {Script} from "forge-std/Script.sol";
import {GovernanceToken} from "../src/GovernanceToken.sol";
contract DeployGovernanceToken is Script {
    function run() external {
        vm.startBroadcast();
        new GovernanceToken();
        vm.stopBroadcast();
    }
}
 Este texto define a la función que la fuente ejecutará. / de La pareja le dice a Foundry que envíe transacciones a la red, en lugar de simularlas. run vm.startBroadcast() vm.stopBroadcast() Luego, lanzaremos una red local de Ethereum usando (en un terminal separado): Anvil anvil
 Anvil inicia un nodo local en y imprime una lista de cuentas prefinanciadas junto con sus claves privadas. http://127.0.0.1:8545 Con Anvil en marcha, podemos implementar el contrato utilizando : forge script forge script script/DeployGovernanceToken.s.sol \
  --rpc-url http://127.0.0.1:8545 \
  --broadcast \
  --private-key <ANVIL_PRIVATE_KEY>
 La URL de RPC y la clave privada se toman directamente de la salida de Anvil.Cuando el comando es exitoso, Foundry imprime el hash de la transacción, la dirección del contrato desplegado, el uso del gas y el número del bloque en el que se creó el contrato. Para verificar rápidamente que la implementación funcionó, podemos consultar el contrato implementado utilizando Por ejemplo, llamar confirma que la menta inicial ocurrió como se esperaba: cast totalSupply() cast call <DEPLOYED_CONTRACT_ADDRESS> \
  "totalSupply()(uint256)" \
  --rpc-url http://127.0.0.1:8545
 El valor devuelto corresponde a ), coincidiendo con la cantidad fijada en el constructor. 1,000,000 tokens with 18 decimals (1000000000000000000000000 [1e24] En esta etapa, nuestro token de gobernanza está en vivo en una red local y listo para ser usado para probar el voto, la delegación y, finalmente, la gobernanza del DAO. Prueba el token Para validar el comportamiento de nuestro token de gobernanza, podemos escribir pruebas de unidad usando , el marco de pruebas de Foundry. las pruebas viven en el El libro está escrito en solidez. forge-std test/ A continuación se muestra una prueba que verifica la La función funciona como se esperaba: mint // test/GovernanceToken.t.sol
pragma solidity ^0.8.20;
import {Test} from "forge-std/Test.sol";
import {GovernanceToken} from "../src/GovernanceToken.sol";
contract TokenTest is Test {
    GovernanceToken token;
    function setUp() public {
        token = new GovernanceToken();
    }
    function testMint() public {
        uint256 before = token.balanceOf(address(this));
        token.mint(address(this), 100);
        uint256 after_ = token.balanceOf(address(this));
        assertEq(after_ - before, 100);
    }
}
 El La función se ejecuta antes de cada prueba y implementa una nueva instancia de , garantizando el aislamiento entre los casos de prueba. La función luego comprueba que la llamada aumenta el saldo del destinatario por el importe esperado. setUp GovernanceToken testMint mint Ejecutar la suite de pruebas es tan simple como: forge test
 Foundry compila los contratos, ejecuta la prueba y informa de los resultados.Una prueba aprobada confirma que la lógica de la moción de nuestro token se comporta correctamente. Conclusión En este artículo, abordamos el primer bloque de construcción de un DAO: el Comenzamos examinando el propio contrato de token, con especial atención a los módulos de OpenZeppelin que hereda y las características adicionales relacionadas con la gobernanza que proporcionan. governance token Después de esto, realizamos el proceso de desarrollo completo utilizando - desde la inicialización de un proyecto, hasta la implementación del token en una red local de Anvil, y finalmente la validación de su comportamiento con pruebas de unidades. Foundry En las siguientes partes de esta serie, construiremos sobre ella introduciendo la delegación, la mecánica de votación y los contratos de gobernanza básicos que transforman este token en un DAO totalmente funcional en cadena. Espero que haya encontrado este artículo útil. siéntese libre de gustar, compartir y suscribirse para más contenido en la serie. Miscellaneous: comandos adicionales Todos los comandos que se muestran en este artículo se ejecutan dentro de un contenedor Docker creado con el siguiente comando: docker run -it ubuntu:ubuntu@sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782
 El uso de un digest de imagen pinchado garantiza , ya que el entorno será siempre el mismo, independientemente de cuándo o dónde se lance el contenedor. full reproducibility para correr en un terminal separado, simplemente conectamos al mismo contenedor: Anvil docker exec -it <CONTAINER_NAME> bash
anvil
 La variable Se puede encontrar a través del comando: «Nombre de contador» $ docker ps
 Foundry también le permite ejecutar scripts de implementación El siguiente comando ejecuta el script en un entorno simulado y informa del uso del gas, sin transmitir ninguna transacción: without forge script script/DeployGovernanceToken.s.sol --broadcast
 Este modo es útil para validar rápidamente la lógica de despliegue y estimar los costos del gas.Si desea simular o ejecutar transacciones contra una red real (local o remota), simplemente proporcione una URL de RPC utilizando el La bandera. --rpc-url Miscellaneous: Advertencias Durante el desarrollo, puede encontrar advertencias relacionadas con dependencias en lugar de sus propios contratos. En nuestro caso, el compilador emitió advertencias originadas en el La Biblioteca : lib/forge-std Warning (2424): Natspec memory-safe-assembly special comment for inline assembly is deprecated
and scheduled for removal. Use the memory-safe block annotation instead.
   --> lib/forge-std/src/StdStorage.sol:301:13
 Estas advertencias son causadas por una entre el compilador Solidity y la versión instalada de Versiones más recientes de Solidity deprecat Comentarios en favor de la la anotación de bloque, mientras que las versiones más antiguas de la biblioteca todavía pueden usar la sintaxis depreciada. version mismatch forge-std @memory-safe-assembly memory-safe Dado que el problema se origina en una dependencia, la solución más sencilla es actualizar Para la última versión: forge-std cd lib/forge-std
git pull origin master
git checkout master
cd -
 Después de actualizar la biblioteca, las advertencias desaparecen y el proyecto compila de nuevo limpio. Esto es un buen recordatorio de que las advertencias del compilador no siempre son causadas por su propio código. Cuando se trabaja con cadenas de herramientas que evolucionan rápidamente como Foundry y Solidity, a menudo es necesario mantener las dependencias actualizadas para evitar advertencias ruidosas o engañosas.

Read My Stories

Este audio es producido en el idioma original de la historia!

Cómo construir un DAO desde cero con Solidity y Foundry, Parte 1: Diseñar el token de gobernanza

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps