On-Chain Governance: The Tech Stack Explained

Про управління говорять як про політичний процес, але механізм його — чиста інженерія програмного забезпечення: смарт-контракти, облік токенів та правила консенсусу, які визначають, хто може змінювати систему та як. Якщо ви оцінюєте DAO або шлях оновлення протоколу, розуміння технічного стеку важливіше, ніж читання заяви про місію.

Основні компоненти

Більшість систем управління on-chain побудовані з невеликої кількості частин:

• Контракти голосування — відстежують пропозиції, підраховують голоси та забезпечують пороги кворуму
• Зважування на токені або репутації — визначає, скільки коштує голос з цієї адреси (зважене за токеном, квадратичне або делеговане)
• Контракти timelock — затримують виконання прийнятих пропозицій, зазвичай на 24-72 години, щоб користувачі могли відреагувати до того, як зміни вступлять в силу
• Модулі виконання — шлях коду, який насправді викликає відповідні контракти після того, як голосування пройде

Compound's Governor Bravo та OpenZeppelin's Governor контракти — це еталонні реалізації, які більшість новіших проектів форкують або розширюють. Якщо ви прочитаєте один кодовий базис, щоб зрозуміти паттерн, прочитайте Governor.sol від OpenZeppelin — він добре прокоментований і показує весь цикл пропозиції: propose, vote, queue, execute.

Як пропозиція насправді рухається через систему

Пропозиція — це не просто пост на форумі, який неформально голосується. On-chain це calldata: адреса цільового контракту, селектор функції та закодовані параметри. Коли хтось подає пропозицію управління, вони подають точну транзакцію, яка виконається, якщо голосування пройде.

Потік зазвичай виглядає так:

1. Пропонент подає calldata та опис, часто вимагаючи мінімального балансу токенів, щоб запобігти спамові
2. Затримка голосування (зазвичай від 1 блоку до кількох днів) дає трималкам час на огляд перед відкриттям голосування
3. Період голосування йде (Compound за замовчуванням використовує приблизно 3 дні, хоча багато форків налаштовують довші вікна)
4. Якщо досягнуті пороги кворуму та затвердження, пропозиція потрапляє в timelock
5. Після закінчення затримки timelock будь-хто може викликати execute, щоб запустити транзакцію

Цей розрив між закриттям голосування та виконанням — це запобіжник безпеки. Це вікно, в якому спільнота може помітити зловмисну або помилкову пропозицію і, в екстремальних випадках, координувати невідкладну відповідь — за умови, що протокол має роль екстреного опікуна або перевизначення multisig, що багато з них мають на ранніх етапах управління.

Де логіка зважування ускладнюється

Просте голосування, зважене за токеном, має відому проблему: хто тримає найбільше токенів, контролює результати, а явка виборців зазвичай низька. Кілька форумів управління повідомляють про явку в однозначні відсотки від обігу для звичайних пропозицій.

Проекти спробували кілька виправлень:

• Делегування — власники токенів призначають свою влаcтивість голосування делегату без передачі токенів, що визначає, як Compound та Uniswap займаються представницьким голосуванням
• Квадратичне голосування — вартість додаткових голосів зростає квадратично, що має на меті зменшити домінування китів, хоча стійкість до Sybil (одна людина створює багато адрес) залишається відкритою проблемою
• Голосування переконань — використовується деякими інструментами поблизу Gitcoin, де влаcтивість голосу накопичується, чим довше токени залишаються прив'язані до позиції, надаючи перевагу стійким уподобанням над snapshot голосами

Жоден з них не вирішує повністю динаміку низької явки та схильності до плутократії при голосуванні за токеном. Це пом'якшення, а не виправлення, і будь-який запис глосарію, який стверджує інше, перепродає технологію.

Off-chain сигналізація проти on-chain виконання

Більшість того, що називається