קופת DAO מרובת חתימות: פיתוח, ביקורת, אינטגרציה

Мультисиг-казначейство DAO: где ломается управление активами

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

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

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

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

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

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

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

Что даёт пороговая схема подписей и разделение ролей

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

Роли при этом разделяются — инициатор готовит перевод и обоснование, подписанты проверяют получателя и назначение.

Чек-лист, по которому проверяем казначейство перед выводом в основную сеть:

• Порог и состав. Порог m из n и список держателей закреплены в контракте; смена состава — отдельное подтверждённое предложение, а не правка одним ключом.
• Разделение ролей подписантов. Инициатор не подтверждает собственную операцию: доля ручных согласований падает, а перевод «в одно касание» становится невозможен.
• Время согласования операции. Очередь предложений со статусом и напоминаниями сжимает согласование с дней до часов — видно, чего ждёт операция и кто её держит.
• Потеря доступа. Порог ниже общего числа держателей: выбывание одного подписанта не блокирует казну, класс отказов «управление встало» уходит.
• Лимиты и выдержка. Крупные переводы — повышенный порог и пауза, мелкие — упрощённый порядок; сценарий «ушло раньше, чем заметили» закрыт.
• Журнал и интеграция. Каждое подтверждение и отклонение остаётся в открытом журнале с подписью, учёт сходится с фактическими ролями — конфигурацию собираем на проверенных стандартах вроде Gnosis Safe.

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

Варианты организации казначейства: сравнение подходов

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

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

От этого зависит, кто видит состав казначейства, как быстро проходит платёж и что происходит при компрометации одной доли.

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

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

Этапы внедрения: от схемы подписей до передачи в эксплуатацию

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

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

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

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

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

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

Кейс: согласование операции за минуты вместо часов

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

Что показывали метрики до

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

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

Что изменили и что стало

Казначейство собрали как мультисиг-контур на Safe: порог подписей, отдельные роли инициатора, согласующего и казначея, единая очередь заявок со статусами.

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

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

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

Что делать, если ключи уже распределены между подписантами?

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

Сначала рядом с текущим адресом разворачивается новый мульсиг-кошелёк с порогом M-из-N и расширенным составом. Прежняя схема один раз подписывает передачу прав, и казначейство DAO продолжает платить уже под новым порогом — паузы в выплатах нет.

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

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

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

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

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

Технические сомнения: безопасность, восстановление, совместимость

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

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

Что происходит при потере доступа участника?

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

Совместимо ли это с текущим окружением?

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

Что даёт аудит схемы подписей?

Аудит — это проверка конфигурации и сценариев, а не только кода. Разбираем порог и распределение ключей, права на смену состава, обработку сбоя подписи и повторного исполнения операции. На выходе — отчёт с приоритетами и списком того, что закрывается до запуска.

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

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

• Текущее состояние. Адреса контрактов и сети, если казначейство уже развёрнуто, либо описание того, как средства и права хранятся сейчас.
• Модель управления. Кто подписанты и сколько их, какой порог срабатывания, нужны ли роли с разными правами и разделение на группы по направлениям.
• Сценарии операций. Разовые переводы, регулярные начисления, вызовы внешних контрактов — под каждый сценарий своя логика подтверждений и лимитов.
• Требования к доступам и безопасности. Аппаратные кошельки, отложенное исполнение, лимиты на операции, порядок замены и отзыва подписанта.
• Интеграции. Реестр участников, панель управления, отчётность, внешние сервисы, к которым обращается казначейство.
• Регулярные процессы. Кто инициирует транзакции, как фиксируются решения, какие записи нужны для внутреннего контроля.

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

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