On-Chain Governance: Tech Stack-ul explicat

Guvernanța se discută ca și cum ar fi un proces politic, dar mecanismul din spatele ei este inginerie pură de software: contracte inteligente, contabilitate de tokenuri și reguli de consens care decid cine poate schimba un sistem și cum. Dacă evaluezi un DAO sau o cale de upgrade a unui protocol, înțelegerea tech stack-ului conteaza mai mult decât citirea declarației de misiune.

Componentele principale

Mayoritatea sistemelor de guvernanță on-chain sunt construite din un set mic de componente:

• Contracte de votare — urmăresc propunerile, numără voturile și aplică praguri de cvorum
• Ponderare de token sau reputație — determină cât de mult contează votul unei anumite adrese (ponderat după tokenuri, pătratic sau delegat)
• Contracte timelock — întârzie executarea propunerilor aprobate, de obicei 24-72 de ore, pentru ca utilizatorii să poată reacționa înainte ca schimbările să fie implementate
• Module de execuție — calea de cod care apelează efectiv contractele afectate după ce un vot trece

Governor Bravo al Compound și contractele Governor de la OpenZeppelin sunt implementările de referință pe care majoritatea proiectelor mai noi le fork-uiesc sau le extind. Dacă citești o bază de cod pentru a înțelege modelul, citește Governor.sol de la OpenZeppelin — e bine comentat și arată întregul ciclu de viață al unei propuneri: propunere, vot, coadă, execuție.

Cum se mișcă o propunere prin sistem

O propunere nu este doar o postare pe un forum care se votează informal. On-chain, este calldata: o adresă de contract țintă, un selector de funcție și parametri codificați. Când cineva trimite o propunere de guvernanță, trimite exact tranzacția care va executa dacă votul trece.

Fluxul arată de obicei așa:

1. Propunătorul trimite calldata plus o descriere, adesea cerând un sold minim de tokenuri pentru a preveni spam
2. O întârziere de votare (de obicei 1 bloc până la câteva zile) dă deținătorilor timp să revizuiască înainte de deschiderea votării
3. Perioada de votare se desfășoară (Compound folosește aproximativ 3 zile implicit, deși multe fork-uri configurează ferestre mai lungi)
4. Dacă pragurile de cvorum și aprobare sunt îndeplinite, propunerea se pune în coadă într-un timelock
5. După ce expira întârzierea timelock, oricine poate apela execuția pentru a rula tranzacția

Această diferență între închiderea votării și execuție este bariera de securitate. E fereastra în care o comunitate poate observa o propunere malițioasă sau cu bug și, în cazuri extreme, coordona un răspuns de urgență — presupunând că protocolul are un rol de gardian de urgență sau un override multisig, ceea ce multe au în faza inițială a guvernanței.

Unde logica ponderării devine complicată

Votarea simplă ponderată după tokenuri are o problemă cunoscută: oricine deține cei mai mulți tokenuri controlează rezultatele, iar participarea alegătorilor este de obicei scăzută. O mână de forumuri de guvernanță raportează participare în procente cu o singură cifră din oferta circulantă pentru propunerile de rutină.

Proiectele au încercat mai multe soluții:

• Delegare — deținătorii de tokenuri asignează puterea lor de vot unui delegat fără a transfera tokenuri, lucru cum fac Compound și Uniswap pentru votarea reprezentativă
• Votare pătratică — costul voturilor suplimentare crește pătratic, intenționat să reducă dominanța balenelor, deși rezistența Sybil (o persoană creând mai multe adrese) rămâne o problemă deschisă
• Votare de convicție — folosită de unele instrumente adiacente Gitcoin, unde puterea de vot se acumulează cu cât mai mult tokenurile rămân angajate într-o poziție, favorizând preferința susținută în detrimentul voturilor snapshot

Niciunul dintre acestea nu rezolvă complet dinamica de participare scăzută, plutocratică a votării cu tokenuri. Sunt atenuări, nu reparații, și orice intrare de glosar care pretinde altfel supraevaluează tehnologia.

Semnalizare off-chain versus execuție on-chain

O mare parte din ceea ce se numește