a is een systeem dat collectieve besluitvorming via code mogelijk maakt, zonder afhankelijk te zijn van traditionele organisatorische hiërarchieën zoals raad van bestuur, CEO's of CTO's. Geplaatst op een blockchain. DAO (Decentralized Autonomous Organization) smart contracts In zijn kern stelt een DAO deelnemers in staat om - het en transparant en verifieerbaar.Het stemrecht is meestal afgeleid van de gehouden door deelnemers, waarbij elke token een eenheid van stemgewicht vertegenwoordigt. propose vote execute decisions tokens A typical on-chain DAO is composed of three main smart contracts: 
 
 
 
 Token contract: Definieert de governance token en volgt stemmacht. Governor contract: beheert voorstellen en stemmingslogica: wie kan voorstellen, hoe stemmen worden geteld, quorumvereisten en voorstelresultaten. Timelock contract: fungeert als een beveiligingslaag door een vertraging tussen de goedkeuring van het voorstel en de uitvoering op te leggen, waardoor deelnemers tijd krijgen om te reageren op potentieel schadelijke beslissingen. De levenscyclus van een voorstel is eenvoudig maar krachtig: een voorstel wordt , stemmen worden verzameld op basis van token eigendom, en zodra het voorstel is goedgekeurd, wordt het doorgestuurd naar de Als het voorstel mislukt, wordt het eenvoudigweg weggegooid. Governor Timelock In deze artikelreeks bouwen we een DAO vanaf de grond met behulp van In dit gedeelte ( , zullen we ons richten op het schrijven, implementeren en testen van de die wij zullen noemen Deze token zal later worden gebruikt om on-chain stemming en besluitvorming in de DAO mogelijk te maken. Openhoekje Part 1) governance token GovernanceToken Openhoekje De token code Zonder verder te gaan, hier is de code: // 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);
    }
}
 In vergelijking met een traditionele ERC20 token, Integreert twee extra OpenZeppelin modules: en . GovernanceToken ERC20Permit ERC20Votes 
 
 ERC20Votes voegt governance-specifieke functionaliteit toe, vooral getPastVotes(account, blockNumber). Deze functie geeft de stemmacht van een account terug op een specifiek blok, in plaats van zijn huidige saldo. 
 
 ERC20Permit maakt gasloze goedkeuring via handtekeningen mogelijk (EIP-2612), waardoor gebruikers stemrecht kunnen delegeren of goedkeuren zonder een transactie in de keten te verzenden. De belangrijkste logica ligt in de , die alle geërfde modules initialisert en een miljoen governance tokens aan de implementator munt. functie, beperkt tot de contracthouder, om gecontroleerde tokenuitgifte na de implementatie toe te staan (nuttig voor testen of toekomstige governancebeslissingen). constructor mint Twee belangrijke functies - en — moeten expliciet worden overgedragen. Dit is vereist omdat ze worden gedefinieerd in meerdere oudercontracten. Zorg ervoor dat alle geërfde gedragingen correct worden samengesteld en dat de erfenisconflicten van de compilator netjes worden opgelost. _update nonces super Het bouwen van de token Om onze governance token te bouwen, zullen we De volgende stappen veronderstellen een Linux-omgeving, maar de workflow is vergelijkbaar op macOS. Foundry We beginnen met het installeren van Foundry met behulp van het officiële installatie script: curl -L https://foundry.paradigm.xyz | bash
 Na de installatie geeft het script ons instructies om onze shellomgeving bij te werken en de Foundry binaries te installeren: source ~/.bashrc   # path may vary depending on your system
foundryup
 Hiermee wordt de volledige Foundry toolchain geïnstalleerd: (Bouw en testen) (CLI interacties zijn (de lokale node) en (Voor het herstel) forge cast anvil chisel Vervolgens initialiseren we een nieuw Foundry-project in een lege map: mkdir DAO
cd DAO
forge init
 Hierdoor ontstaat een compleet projectplan, waaronder - het en directories. Standaard creëert Foundry een voorbeeld Omdat we alleen de projectstructuur willen, kunnen we deze voorbeeldbestanden veilig verwijderen en vervangen door onze eigen contracten. src/ script/ test/ Counter Voorlopig voegen we onze governance token toe onder : src/ src/
└── GovernanceToken.sol
 (Het bevat de overeenkomst zoals gedefinieerd in de vorige paragraaf.) GovernanceToken Omdat onze token afhankelijk is van OpenZeppelin-modules, moeten we de OpenZeppelin Contracts-bibliotheek installeren: forge install OpenZeppelin/openzeppelin-contracts
 Deze opdracht levert OpenZeppelin in de Directory en maakt zijn contracten beschikbaar voor import binnen ons project. lib/ Tot slot maken we het project samen: forge build
 Als alles correct is ingesteld, voltooit de compilatie met succes en genereert een Deze map bevat de gecompileerde artefacten (ABIs en bytecode) voor en alle erfelijke OpenZeppelin-afhankelijkheden. out/ GovernanceToken Op dit moment is onze governance token volledig samengesteld en klaar om te worden ingezet en getest - stappen die we in de volgende secties zullen behandelen. Het implementeren van de token Met de governance token samengesteld, kunnen we het nu implementeren op een lokale blockchain. . deployment scripts We beginnen met het maken van een deployment script Onder de De directie: 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();
    }
}
 Dit script definieert een functie die Foundry zal uitvoeren. de / van Paar vertelt Foundry om transacties naar het netwerk te sturen, in plaats van ze te simuleren. run vm.startBroadcast() vm.stopBroadcast() Vervolgens starten we een lokaal Ethereum-netwerk met behulp van (in een afzonderlijke terminal): Anvil anvil
 Anvil start een lokale knoop op en een lijst met vooraf gefinancierde accounts samen met hun privé-sleutels afdrukken. http://127.0.0.1:8545 Met Anvil in werking, kunnen we het contract met behulp van : forge script forge script script/DeployGovernanceToken.s.sol \
  --rpc-url http://127.0.0.1:8545 \
  --broadcast \
  --private-key <ANVIL_PRIVATE_KEY>
 De RPC-URL en de private sleutel worden rechtstreeks van de output van Anvil genomen.Wanneer de opdracht succesvol is, printeert Foundry de transactieshash, het geïmplementeerde contractadres, het gasgebruik en het bloknummer waarin het contract is gemaakt. Om snel te verifiëren dat de implementatie werkte, kunnen we het gedistribueerde contract aanvragen met behulp van Bijvoorbeeld door te bellen bevestigt dat de oorspronkelijke munt plaatsvond zoals verwacht: cast totalSupply() cast call <DEPLOYED_CONTRACT_ADDRESS> \
  "totalSupply()(uint256)" \
  --rpc-url http://127.0.0.1:8545
 De teruggegeven waarde komt overeen met ), het overeenkomen met het in de constructor geminte bedrag. 1,000,000 tokens with 18 decimals (1000000000000000000000000 [1e24] In dit stadium is onze governance token live op een lokaal netwerk en klaar om te worden gebruikt voor het testen van stemming, delegatie en uiteindelijk - DAO governance. Het testen van de token Om het gedrag van onze governance token te valideren, kunnen we eenheidstests schrijven met behulp van , Foundry's test framework. Tests live in de Directory en zijn geschreven in Solidity. forge-std test/ Hieronder volgt een eenvoudige test die de De functie werkt zoals verwacht: 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);
    }
}
 De functie wordt uitgevoerd vóór elke test en implementeert een nieuw de isolatie tussen de testgevallen te garanderen. de functie controleert dan dat het oproepen verhoogt het saldo van de ontvanger met het verwachte bedrag. setUp GovernanceToken testMint mint Het uitvoeren van de test suite is zo eenvoudig als: forge test
 Foundry compileert de contracten, voert de test uit en rapporteert de resultaten.Een doorlopende test bevestigt dat de muntlogica van onze token correct gedraagt. Conclusie In dit artikel hebben we de eerste bouwstenen van een DAO aangepakt: de We begonnen met het onderzoeken van het tokencontract zelf, met bijzondere aandacht voor de OpenZeppelin-modules die het erft en de extra governance-gerelateerde functies die ze bieden. governance token We gingen vervolgens door de volledige ontwikkelingswerkstroom met behulp van - van het initialiseren van een project, tot het implementeren van de token op een lokaal Anvil-netwerk, en uiteindelijk het valideren van het gedrag ervan met eenheidstests. Foundry In de volgende delen van deze serie, zullen we bouwen op het door het introduceren van delegatie, stemmingsmechanismen, en de kern governance contracten die deze token transformeren in een volledig functionele on-chain DAO. Ik hoop dat u dit artikel nuttig vond. Voel je vrij om leuk te vinden, te delen en te abonneren voor meer inhoud in de serie. Miscellaneous: Extra opdrachten Alle opdrachten die in dit artikel worden weergegeven, werden uitgevoerd in een Docker-container die is gemaakt met de volgende opdracht: docker run -it ubuntu:ubuntu@sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782
 Met behulp van een geplaveide afbeelding digest zorgt , omdat de omgeving altijd hetzelfde zal zijn, ongeacht wanneer of waar de container wordt gelanceerd. full reproducibility Twee rennen in een afzonderlijke terminal, we gewoon bevestigd aan dezelfde container: Anvil docker exec -it <CONTAINER_NAME> bash
anvil
 De variabele Dit kan via de opdracht: De naam van de container $ docker ps
 Foundry stelt u ook in staat om deployment scripts uit te voeren De volgende opdracht voert het script uit in een gesimuleerde omgeving en rapporteert gasgebruik, zonder transacties uit te zenden: without forge script script/DeployGovernanceToken.s.sol --broadcast
 Deze modus is handig voor het snel valideren van de implementatielogica en het schatten van gaskosten.Als u transacties wilt simuleren of uitvoeren tegen een feitelijk netwerk (lokale of externe), voert u eenvoudig een RPC-URL toe met behulp van de De vlag. --rpc-url Miscellaneous: waarschuwingen Tijdens de ontwikkeling kunt u waarschuwingen tegenkomen die verband houden met afhankelijkheden in plaats van met uw eigen contracten. Bij de bibliotheek: 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
 Deze waarschuwingen worden veroorzaakt door een tussen de Solidity compiler en de geïnstalleerde versie van Nieuwere versies van Solidity deprecate de NatSpec commentaar ten gunste van de blok annotatie, terwijl oudere bibliotheekversies nog steeds de afgedankte syntax gebruiken. version mismatch forge-std @memory-safe-assembly memory-safe Aangezien het probleem is ontstaan in een afhankelijkheid, de eenvoudigste oplossing is om de update Tot de nieuwste versie: forge-std cd lib/forge-std
git pull origin master
git checkout master
cd -
 Na het bijwerken van de bibliotheek verdwijnen de waarschuwingen en compileert het project opnieuw. Dit is een goede herinnering dat compilerwaarschuwingen niet altijd worden veroorzaakt door uw eigen code.Wanneer u werkt met snel evoluerende toolchains zoals Foundry en Solidity, is het vaak noodzakelijk om afhankelijkheden up-to-date te houden om lawaaierige of misleidende waarschuwingen te voorkomen.

Read My Stories

Deze audio wordt geproduceerd in de originele taal van het verhaal!

Hoe maak je een DAO vanaf de grond met Solidity en Foundry, deel 1: Het ontwerpen van de governance token

About Author

OPMERKINGEN

LABELS

DIT ARTIKEL WERD GEPRESENTEERD IN

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps