On-Chain Governance: Tech Stack wyjaśniony

Zarządzanie jest omawiane jak proces polityczny, ale mechanizm za nim to czysty software engineering: smart contracts, liczenie tokenów i reguły konsensusu, które decydują, kto może zmienić system i jak. Jeśli oceniasz DAO lub ścieżkę uaktualnienia protokołu, zrozumienie tech stacku ma większe znaczenie niż czytanie deklaracji misji.

Komponenty podstawowe

Wiekszość systemów zarządzania on-chain zbudowana jest z małego zestawu części:

• Voting contracts — śledzą propozycje, sumują głosy i egzekwują progi quorum
• Token lub reputation weighting — określa, ile liczy się głos danego adresu (token-weighted, quadratic lub delegowany)
• Timelock contracts — opóźniają wykonanie zatwierdonych propozycji, zwykle 24-72 godziny, aby użytkownicy mogli zareagować zanim zmiany wejdą w życie
• Execution modules — ścieżka kodu, która faktycznie wywołuje dotknięte kontrakty po przejściu głosowania

Compound's Governor Bravo i OpenZeppelin's Governor contracts to implementacje referencyjne, które większość nowszych projektów fork lub rozszerza. Jeśli przeczytasz jeden codebase aby zrozumieć wzorzec, przeczytaj Governor.sol z OpenZeppelin — jest dobrze skomentowany i pokazuje pełny cykl życia propozycji: propose, vote, queue, execute.

Jak propozycja faktycznie przemieszcza się przez system

Propozycja to nie tylko post na forum, na który głosuje się nieformalnie. On-chain to calldata: adres kontraktu docelowego, selektor funkcji i zakodowane parametry. Gdy ktoś przesyła propozycję zarządzania, przesyła dokładną transakcję, która będzie wykonana jeśli głosowanie przejdzie.

Przebieg zazwyczaj wygląda tak:

1. Proposer przesyła calldata plus opis, często wymagając minimalnego salda tokenów aby zapobiec spamowi
2. Opóźnienie głosowania (zwykle 1 blok do kilku dni) daje posiadaczom czas na przegląd zanim głosowanie się otwiera
3. Okres głosowania trwa (Compound domyślnie używa mniej więcej 3 dni, choć wiele forków konfiguruje dłuższe okna)
4. Jeśli progi quorum i zatwierdzenia są spełnione, propozycja trafia do timelock
5. Po upłynięciu opóźnienia timelock, każdy może wywołać execute aby uruchomić transakcję

Luka między zamknięciem głosowania a wykonaniem to zabezpieczenie. To okno, w którym społeczność może zauważyć złośliwą lub błędną propozycję i w skrajnych przypadkach koordynować nadzwyczajną odpowiedź — zakładając że protokół ma rolę emergency guardian lub multisig override, co wiele z nich ma w wczesnych fazach zarządzania.

Gdzie logika weightingu staje się skomplikowana

Proste token-weighted voting ma znany problem: kto posiada najwięcej tokenów kontroluje wyniki, a frekwencja głosów zwykle jest niska. Garstka governance forów raportuje frekwencję w jednocyfrowych procentach krążącego zasobu dla rutynowych propozycji.

Projekty próbowały kilka rozwiązań:

• Delegation — posiadacze tokenów przypisują swoją siłę głosu delegatowi bez transferu tokenów, to jak Compound i Uniswap obsługują głosowanie reprezentacyjne
• Quadratic voting — koszt dodatkowych głosów rośnie kwadratowo, ma na celu zmniejszenie dominacji wielorybów, choć Sybil resistance (jedna osoba tworząca wiele adresów) pozostaje otwartym problemem
• Conviction voting — używane przez niektóre narzędzia związane z Gitcoin, gdzie siła głosu kumuluje się im dłużej tokeny pozostają zaangażowane w pozycję, faworyzując trwałą preferencję nad snapshot votes

Zaden z nich w pełni nie rozwiązuje dynamiki niskiej frekwencji i skłonności plutokracji głosowania tokenowego. To są mitygacje, nie rozwiązania, i każdy wpis słownika, który twierdzi inaczej, zbyt wiele obiecuje na temat technologii.

Sygnalizacja off-chain versus egzekucja on-chain

Mnego z tego, co jest nazywane