Разработка смарт-контрактов governance для DAO

Разработка governance смарт-контрактов: где ломается управление

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

Второй класс поломок — кворум и пороги голосования. Без минимальной доли проголосовавших предложение набирает несколько голосов при общей массе держателей — и проходит. Обратная крайность — пороги, которые не собираются никогда: заявка висит в статусе «на рассмотрении», решения не принимаются, а участники теряют интерес к голосованию.

Третий слой — исполнение предложений. Вызов падает, если контракт-получатель не выдал разрешение, сумма превышает доступный баланс казны или данные для вызова собраны неверно. Транзакция не проходит, права остаются на месте, казна зависает: средства заблокированы, а разблокировка требует нового решения и повторного голосования.

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

Измеримый эффект: скорость решений и устойчивость казны

Мы фиксируем метрики до разработки, иначе эффект governance-контура остаётся декларацией. Первая — время от публикации предложения до исполнения: при ручном проведении через мультиподписной кошелёк оно измерялось днями, потому что подписи собирались по цепочке и каждая транзакция ждала дежурного. Связка «голосование — порог кворума — отложенное исполнение» сжимает этот путь до часов: вызов уходит в сеть по расписанию, без участия человека.

Вторая — доля решений, исполненных без ручного вмешательства. Контур на базе OpenZeppelin Governor делает исполнение следствием достигнутого порога, а не действием оператора: подпись нужна только на публикацию предложения. Делегирование голосов работает на ту же метрику — держатель передаёт вес представителю, и кворум набирается без голосования каждым участником.

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

Доступность управления — тоже метрика. Голосовать можно из браузера, делегировать вес или отозвать его при выходе из объединения; порог кворума и задержку настраиваем под масштаб участников. В сумме получается предсказуемый цикл: предложение доходит до исполнения за часы, большинство решений не требует оператора, а опасные сценарии закрыты на уровне кода.

Форматы управления: мультиподпись, гибрид, голосование на цепи

Схема управления задаётся ответами на три вопроса: кто формирует решение, где фиксируется результат и что исполняется автоматически. Мультиподпись решает это порогом подписей — например, пять хранителей и три подписи, после чего операция проходит. Быстро и предсказуемо, но расширять круг участников так нельзя: каждое новое лицо меняет и порог, и порядок согласования.

Гибридное голосование разделяет учёт мнений и исполнение: сообщество голосует вне цепи по заранее описанным правилам, а итог подписывает ответственный орган. Голосование на цепи убирает посредника, но каждая операция становится транзакцией — на активном сообществе это упирается в скорость и ресурс сети.

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

Этапы внедрения governance: от аудита до передачи

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

1. Аудит управления. Разбираем, как решения принимаются сейчас: кто инициирует, кто согласует, где согласование вне сети превращается в транзакцию. На выходе — карта прав и точек, где один участник проводит решение в одиночку.
2. Схема ролей и прав. Раскладываем полномочия: кто предлагает, кто голосует, кто исполняет, у кого аварийные права. Каждое право получает владельца и срок действия.
3. Настройка контрактов. Собираем модуль голосования, пороги кворума, задержку перед исполнением и механику отмены. Параметры берём из схемы ролей, а не «по умолчанию».
4. Проверка сценариев голосования. Прогоняем спорные случаи: кворум не собран, ключ утерян, решение принято и отменено, участник вышел. Каждый сценарий — тест с ожидаемым результатом.
5. Передача управления заказчику. Переводим права на вашу мультиподпись, отзываем технические доступы, фиксируем процедуру обновления контрактов.
6. Регламент и обучение. Отдаём инструкции владельцам ролей: как вынести предложение, как голосовать, что делать при сбое.

После передачи у вас остаётся рабочая система и понятная процедура изменений — без зависимости от нашей команды в ежедневных решениях.

Комплект передачи: конфигурации, схемы ролей, регламенты

Комплект передачи — это не папка с исходниками, а описание того, как система ведёт себя под нагрузкой и в спорных ситуациях. Собираем его параллельно с разработкой, поэтому к моменту запуска у каждого параметра есть владелец и обоснование.

• Параметры конфигурации — таблица значений с границами допустимого: порог кворума, длительность голосования, задержка перед исполнением, окно отмены решения. Для каждого указано, кто меняет и по какой процедуре.
• Карта ролей и прав — кто вправе выносить предложения, кто исполнять, кто обновлять логику контрактов, а кто только читать состояние.
• Политики доступа — схема разделения ключей, требуемое число подписей на критичные операции, лимиты на объём действий за период.
• Регламент голосования — жизненный цикл предложения: выдвижение, обсуждение, фиксация снимка долей, подсчёт, исполнение, отмена.
• Регламент разрешения спорных ситуаций — что делать при зависшем предложении, конфликте ролей или ошибке в параметрах: аварийная остановка, арбитраж, повторное голосование.
• Документация управления — описание контрактов, событий и связей между ними, адреса развёрнутых экземпляров и порядок обновления без потери истории голосований.

Такой комплект позволяет команде заказчика самостоятельно менять параметры и разбирать инциденты, а нас подключать точечно — под изменение логики, а не под каждую настройку.

Кейс: перестройка управления казной и голосованием

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

Перестроили управление в контрактный слой: предложение, голосование с прозрачными порогами, очередь исполнения с фиксированной задержкой и только затем казна. За основу взяли OpenZeppelin Governor и доработали под свои роли и правила. Пороги и кворум стали параметрами контракта — изменить их можно лишь новым предложением, обойти задержку нельзя. Ключи распределили: ни один участник не исполняет решение единолично, а каждое действие остаётся в журнале событий.

Метрики до и после

Класс отказов «подписи собраны, но перевод не исполнен» и «параметр изменён без голосования» ушёл полностью: исполнение решений казны теперь либо проходит целиком, либо отклоняется на этапе предложения — и это видно любому участнику.

Чем отличается мультиподпись от голосования на цепи?

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

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

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

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

Вопросы, которые инженеры задают до старта

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

Как контракт защищён от захвата голосов?

Кворум, задержка исполнения и раздельные окна выдвижения и голосования. Делегирование ограничено сроком, поэтому один крупный держатель не проводит решение мгновенно.

Что делать при потере ключей участника?

Ключ голосования отделён от ключа хранения средств. Голосующий кошелёк прикрываем мультиподписью или представителем — доступ восстанавливается без перевыпуска доли.

Обязателен ли внешний аудит контрактов?

До вывода управления на контракт — да. Проверяют подсчёт голосов, права администратора и сценарии отката; замечания закрываем до запуска.

Можно ли менять параметры голосования?

Кворум и длительность периодов вынесены в конфигурацию, а не в код. Меняются тем же голосованием, что и остальные решения.

Обсудим задачу и вернёмся с оценкой и планом

Точная оценка объёма работ строится на вводных по проекту, а не на общих словах об управлении сообществом. Достаточно понять, как решения принимаются сейчас, кто входит в круг голосующих, какие активы находятся под контролем и что уже реализовано в контрактах. Чем конкретнее исходные данные, тем меньше правок в плане внедрения управления на этапе разработки.

Что присылать для разбора на обсуждении задачи:

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

В ответ вернёмся не пересказом задачи, а планом внедрения управления: составом контрактов и их связями, этапами работ, порядком развёртывания, схемой разграничения прав и объёмом проверок перед запуском. Отдельно вынесем допущения, от которых зависит срок, — по ним видно, где оценка может измениться.

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