Како да се изгради DAO од нула со солидност и Foundry, дел 1: Дизајн на токен за управување

А е систем кој овозможува колективно донесување одлуки преку код, без да се потпира на традиционалните организациски хиерархии како што се одбори на директори, извршни директори или ЦТО. Испорака на блокчејн. DAO (Decentralized Autonomous Organization) smart contracts Во своето срце, DAO им овозможува на учесниците да , на и на транспарентен и верифициран начин. гласачката моќ обично произлегува од одржан од страна на учесниците, каде што секој токен претставува единица на тежина на гласање. propose vote execute decisions tokens A typical on-chain DAO is composed of three main smart contracts: Токен договор: Дефинира токен за управување и ја следи моќта на гласање. Договор на гувернерот: управува со предлозите и логиката на гласањето: кој може да предложи, како се бројат гласовите, барањата за кворум и резултатите од предлогот. Timelock договор: Делува како безбедносен слој со спроведување на одложување помеѓу одобрувањето на предлогот и извршувањето, давајќи им на учесниците време да реагираат на потенцијално штетни одлуки. Животниот циклус на предлогот е едноставен, но моќен: предлогот се поднесува на , гласовите се собираат врз основа на сопственост на токен, и откако предлогот е одобрен, тој се пренесува на за одложено извршување.Ако предлогот не успее, тој едноставно се отфрла. Governor Timelock Во оваа серија на статии, ќе изградиме DAO од нула со користење на Во овој дел ( , ќе се фокусираме на пишување, распоредување и тестирање на Кој ќе го наречеме Овој токен подоцна ќе се користи за да се овозможи гласање на синџирот и донесување одлуки во DAO. Отворени Part 1) governance token GovernanceToken Отворени Кодот на токен Без понатамошни напори, еве го кодот: // 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); } } Во споредба со традиционалниот ERC20 токен, Интегрира два дополнителни OpenZeppelin модули: и . GovernanceToken ERC20Permit ERC20Votes ERC20Votes додава функционалност специфична за управување, особено getPastVotes(сметка, блокNumber). Оваа функција ја враќа моќта на гласање на сметката на одреден блок, наместо нејзината тековна рамнотежа. Во контекст на DAO, овој механизам за снимање е критичен: моќта на гласање е фиксирана во моментот кога е создадено предлогот, спречувајќи им на корисниците да манипулираат со гласовите со купување или пренесување токени по фактот. ERC20Permit овозможува безгасни одобрувања преку потписи (EIP-2612), овозможувајќи им на корисниците да делегираат или одобруваат право на глас без да испраќаат трансакција во синџирот. Најважната логика лежи во , која ги инициализира сите наследени модули и наметнува еден милион токени за управување на дистрибутерот. функција, ограничена на сопственикот на договорот, за да се овозможи контролирано издавање на токени по распоредувањето (корисно за тестирање или идни одлуки за управување). constructor mint На крајот, две функции - и – мора да бидат експлицитно надредени. Ова е потребно затоа што тие се дефинирани во повеќе родителски договори. , обезбедување дека сите наследени однесувања се правилно компонирани и дека конфликтите за наследување на компилаторот се решени чисто. _update nonces super Изградба на токен За да го изградиме нашиот токен за управување, ќе користиме Следниве чекори претпоставуваат Linux животната средина, но работниот тек е сличен на macOS. Foundry Започнуваме со инсталирање на Foundry користејќи го официјалниот инсталациски скрипт: curl -L https://foundry.paradigm.xyz | bash По инсталацијата, скриптот ни информира да ја ажурираме нашата средина на школки и да ги инсталираме бинарите Foundry: source ~/.bashrc # path may vary depending on your system foundryup Ова го инсталира целиот Foundry toolchain: (Производство и тестирање) (за интеракции на CLI) (Локалниот нодул) и (Одлуката е во ред) forge cast anvil chisel Следно, ние инициализираме нов проект Foundry во празен директориум: mkdir DAO cd DAO forge init Ова генерира целосна проектна рамка, вклучувајќи , на и директориуми. Подрачливо, Foundry создава пример Бидејќи сакаме само структура на проектот, можеме безбедно да ги отстраниме овие примерни датотеки и да ги замениме со нашите сопствени договори. src/ script/ test/ Бројката Засега, ние го додаваме нашиот токен за управување под : src/ src/ └── GovernanceToken.sol (Содржината на договор дефиниран во претходниот дел.) GovernanceToken Бидејќи нашиот токен се потпира на OpenZeppelin модули, мора да ја инсталираме библиотеката OpenZeppelin договори: forge install OpenZeppelin/openzeppelin-contracts Оваа команда продавачите OpenZeppelin во директориумот и ги прави своите договори достапни за увоз во рамките на нашиот проект. lib/ На крајот, го составивме проектот: forge build Ако сè е поставено правилно, компилацијата успешно се завршува и генерира Оваа папка ги содржи компилираните артефакти (ABIs и bytecode) за како и сите наследени OpenZeppelin зависности. out/ GovernanceToken Во овој момент, нашиот токен за управување е целосно компилиран и подготвен за распоредување и тестирање - чекори што ќе ги покриеме во следните делови. Развивање на токенот Со токенот за управување компилиран, сега можеме да го распоредиме на локален блокчејн. . deployment scripts Започнуваме со создавање на сценарио за имплементација Под на Директор на: 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(); } } Овој текст го дефинира а функција која Foundry ќе ја изврши. / на Парот му кажува на Foundry да испраќа трансакции до мрежата, наместо да ги симулира. run vm.startBroadcast() vm.stopBroadcast() Следно, ќе лансираме локална Ethereum мрежа со користење на (во посебен терминал): Anvil anvil Anvil започнува локален нод на и печати листа на претплатени сметки заедно со нивните приватни клучеви.Овие сметки се наменети само за развој и тестирање. http://127.0.0.1:8545 Со работа на Anvil, можеме да го распоредиме договорот со користење на : forge script forge script script/DeployGovernanceToken.s.sol \ --rpc-url http://127.0.0.1:8545 \ --broadcast \ --private-key URL-то на RPC и приватниот клуч се земаат директно од излезот на Anvil.Кога командата е успешна, Foundry го отпечатува хаширањето на трансакцијата, адресата на договорот што е распоредена, употребата на гас и бројот на блокот во кој е креиран договорот. За брзо да провериме дали распоредувањето функционирало, можеме да го пребаруваме распоредениот договор со користење на На пример, повикувајќи потврдува дека почетната мента се случи како што се очекуваше: cast totalSupply() cast call \ "totalSupply()(uint256)" \ --rpc-url http://127.0.0.1:8545 Вратената вредност одговара на ), споредба на износот измислен во конструкторот. 1,000,000 tokens with 18 decimals (1000000000000000000000000 [1e24] Во оваа фаза, нашиот токен за управување е во живо на локална мрежа и е подготвен да се користи за тестирање на гласање, делегирање и - на крајот - DAO управување. Тестирање на токенот За да го потврдиме однесувањето на нашиот токен за управување, можеме да напишеме единица тестови со користење на , Тестирање рамка на Foundry. Тестовите живеат во Директориум и се напишани во солидност. forge-std test/ Подолу е едноставен тест кој го проверува Функцијата функционира како што се очекува: 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); } } на функцијата се извршува пред секој тест и распоредува нова инстанца на обезбедување на изолација помеѓу случаите на тестирање. функција потоа проверува дека повикува го зголемува балансот на примателот за очекуваниот износ. setUp GovernanceToken testMint mint Извршувањето на тестот е едноставно како: forge test Foundry ги компилира договорите, го спроведува тестот и ги известува резултатите. Заклучок Во оваа статија, се занимаваме со првиот градивен блок на ДАО: Почнавме со испитување на самиот договор за токен, со посебно внимание на OpenZeppelin модулите од кои ги наследува и дополнителните карактеристики поврзани со управувањето што ги обезбедуваат. governance token Потоа поминавме низ целиот работен тек на развој со користење на - од инициализирање на проект, до распоредување на токенот на локалната мрежа на Анвил, и конечно валидирање на неговото однесување со единица тестови. Foundry Во следните делови од оваа серија, ние ќе се изгради на врвот на тоа со воведување на делегирање, гласање механизми, и основните договори за управување кои го трансформираат овој токен во целосно функционален на синџирот DAO. Се надевам дека сте го нашле овој напис корисен. Чувствувајте се слободни да се допадне, споделување, и се претплатите за повеќе содржини во серијата. Miscellaneous: Дополнителни команди Сите команди прикажани во оваа статија се извршени во Docker контејнер создаден со следната команда: docker run -it ubuntu:ubuntu@sha256:72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782 Користењето на прицврстена слика дигест обезбедува , бидејќи животната средина секогаш ќе биде иста без оглед на тоа кога или каде е лансиран контејнерот. full reproducibility Трчање во посебен терминал, ние едноставно се прицврстени на истиот контејнер: Anvil docker exec -it bash anvil Варијантата Може да се најде преку командата: Името на контејнерот $ docker ps Foundry исто така ви овозможува да извршувате скрипти за имплементација Следната команда го извршува скриптот во симулирана средина и ја известува употребата на гас, без да емитува никакви трансакции: without forge script script/DeployGovernanceToken.s.sol --broadcast Овој режим е корисен за брзо валидирање на логиката на распоредување и проценка на трошоците за гас. Ако сакате да симулирате или извршувате трансакции против вистинска мрежа (локална или далечна), едноставно обезбедете RPC URL со користење на Знамето е --rpc-url Ознака: Предупредувања За време на развојот, може да се соочите со предупредувања поврзани со зависности наместо со вашите сопствени договори. Во библиотеката: 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 Овие предупредувања се предизвикани од а помеѓу Solidity компилаторот и инсталираната верзија на Неодамнешните верзии на Solidity ги депретираат Натспек коментира во корист на блок забелешки, додека постарите верзии на библиотеката сè уште може да го користат депресираниот синтакс. version mismatch forge-std @memory-safe-assembly memory-safe Бидејќи проблемот произлегува од зависност, наједноставниот лек е да се ажурира До најновата верзија: forge-std cd lib/forge-std git pull origin master git checkout master cd - По ажурирањето на библиотеката, предупредувањата исчезнуваат и проектот повторно се компилира чисто. Ова е добар потсетник дека предупредувањата на компилаторот не се секогаш предизвикани од вашиот сопствен код. Кога работите со брзо развивачки алатки како Foundry и Solidity, одржувањето на зависностите е често неопходно за да се избегнат бучни или погрешни предупредувања.