On-Chain Governance: The Tech Stack Explained

Об управлении говорят как о политическом процессе, но механизм за ним — это чистая разработка ПО: смарт-контракты, учёт токенов и правила консенсуса, которые определяют, кому разрешено менять систему и как. Если вы оцениваете DAO или путь обновления протокола, понимание техстека важнее, чем чтение декларации о миссии.

Основные компоненты

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

• Контракты голосования — отслеживают предложения, подсчитывают голоса и применяют пороги кворума
• Взвешивание по токенам или репутации — определяет, насколько голос данного адреса влияет на результат (по токенам, квадратичное или делегированное)
• Контракты с таймлоком — откладывают исполнение принятых предложений обычно на 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. Если достигнуты пороги кворума и одобрения, предложение попадает в таймлок
5. После истечения задержки таймлока кто-то может вызвать execute для запуска транзакции

Промежуток между закрытием голосования и исполнением — это подушка безопасности. Это окно, где сообщество может заметить вредоносное или ошибочное предложение и в крайних случаях организовать ответ в чрезвычайной ситуации — при условии, что у протокола есть роль экстренного опекуна или мультиподпись-овверрайд, что часто бывает на ранних этапах управления.

Где логика взвешивания усложняется

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

Проекты попробовали несколько решений:

• Делегирование — держатели токенов назначают своё право голоса делегату без передачи токенов, это то, как Compound и Uniswap реализуют представительное голосование
• Квадратичное голосование — стоимость дополнительных голосов растёт квадратично, предназначено снизить доминирование китов, хотя устойчивость к Sybil-атакам (один человек создаёт много адресов) остаётся открытой проблемой
• Conviction voting — используется в некоторых инструментах рядом с Gitcoin, где сила голоса накапливается, чем дольше токены остаются приверженными позиции, предпочитая устойчивые предпочтения снимку голосов

Ни один из них не решает полностью низкую явку и склонность к плутократии в голосовании по токенам. Это смягчения, а не исправления, и любая статья глоссария, которая утверждает иное, переоценивает технологию.

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

Много из того, что называют