Является ли Web3 DAO псевдопроблемой? Глубокий разбор: почему Bonk подвергся атаке управления.

Автор: Biteye; Источник: X, @BiteyeCN

Что? Злоумышленник смог завладеть казной DAO на 20 миллионов долларов, имея всего 4 миллиона долларов?

Вчера утром DAO проекта BONK подверглось атаке на управление. Злоумышленник использовал низкий порог голосования в BONK, механизм простого большинства и отсутствие временной задержки (Timelock) для выполнения злонамеренного предложения по переводу активов казны.

Как же должен выглядеть процесс управления в зрелом DAO? Почему такие протоколы, как Aave, ENS, Lido, снижают риски с помощью многоуровневого управления, а BONK оказался более уязвимым для атак?

В этой статье мы разберем процесс управления DAO на пяти этапах: Предложение → Обсуждение в сообществе → Snapshot-тест → Голосование в сети → Исполнение через Timelock

1. Этап предложения (Proposal)

В экосистеме DAO этап предложения является отправной точкой всех управленческих действий.

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

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

• Aave: Высокий порог, требуется около 0,5% голосующих прав AAVE.
• ENS: Для исполнительных предложений требуется 100 000 делегированных ENS, для социальных — около 10 000 ENS.
• Lido: Сначала необходимо обсуждение на форуме и выполнение порога не менее 1 000 LDO.
• BONK: Низкий порог, требуется всего 100 млн BONK (425,99 доллара). Это и стало причиной атаки на управление BONK.

2. Этап обсуждения в сообществе (Governance Forum)

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

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

Однако не все DAO имеют этот этап. Например, у BONK DAO нет формального процесса Governance Forum, в основном предложения BIP подаются и голосуются напрямую через Solana Realms.

Зрелые DAO обычно создают защитный барьер управления через многоуровневые механизмы, такие как Governance Forum, Snapshot, Timelock, в то время как Meme DAO, такие как BONK, предпочитают прямое голосование для повышения эффективности принятия решений, что также снижает порог для атак.

3. Snapshot-тест (внецепочечное голосование)

Перед официальным цепным голосованием многие DAO сначала проводят внецепочечное голосование через Snapshot в качестве проверки настроений сообщества.

Этот этап часто называют: Temperature Check (проверка температуры)

Основные функции:

• Снижение затрат на голосование: Внецепочечное голосование не требует оплаты газа, члены сообщества могут участвовать с низкими затратами.
• Заблаговременная проверка консенсуса: Наблюдение, получило ли предложение достаточную поддержку, чтобы незрелые планы не попадали напрямую в цепное исполнение.
• Оптимизация направления предложения: На основе результатов голосования и отзывов сообщества корректируются детали плана.

Если Snapshot-тест не пройден, это обычно означает, что сообщество не достигло достаточного консенсуса, и предложение либо отклоняется, либо возвращается на доработку, не переходя к этапу официального цепного голосования.

Именно из-за отсутствия этого важного защитного механизма Snapshot, который служит страховкой от взлома, «вор» смог легко проникнуть в Bonk DAO.

4. Официальное цепное голосование (On-chain Governance)

После обсуждения в сообществе и Snapshot-теста (если проект его использует) предложение переходит к этапу официального цепного управления.

Этот этап выполняется с помощью фреймворков цепного управления, например:

• Контракт Governor (распространен в экосистеме Ethereum)
• Aragon (фреймворк управления DAO)
• Realms (фреймворк управления Solana)

Для обеспечения серьезности и безопасности цепного голосования смарт-контракты при подсчете строго проверяют два следующих ключевых параметра.

Минимальный порог участия: Как красная линия безопасности управления DAO, Quorum определяет минимальный общий объем голосов, необходимый для юридической действительности предложения.

Если общее количество токенов, участвовавших в голосовании, не достигает кворума, предложение отклоняется, даже если «за» проголосовало 100%.

Например, в модели с общим объемом токенов 100 миллионов, если Quorum установлен на 5%, то для голосования необходимо участие как минимум 5 миллионов токенов. Настройки Quorum в основных DAO различаются:

• Lido установил высокий порог в 5% от общего предложения (около 50 млн LDO)
• Aave (около 2% от общего предложения), ENS и BONK (1% от общего предложения) — относительно стандартные
• Optimism более гибкий: в зависимости от типа предложения кворум варьируется от 3% до 30%.

Условия принятия голосования: После достижения Quorum (минимального порога участия) предложение также должно набрать необходимую долю голосов «за», чтобы быть официально принятым.

Большинство DAO в повседневном управлении используют простое большинство (Simple Majority), то есть: голоса «ЗА» > голосов «ПРОТИВ».

Однако для существенных изменений, затрагивающих основные правила протокола, таких как изменение конституции ENS, корректировка ключевых параметров управления или обновление базового протокола, DAO обычно используют сверхбольшинство (Super Majority).

Требуется более высокий процент голосов «за», например: 2/3 (около 66,7%) и более; или еще более высокий процент поддержки.

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

Еще одна причина атаки на управление BONK заключается в относительно слабых параметрах управления DAO.

Минимальный порог участия составляет всего 1% от общего объема BONK для начала действительного голосования. А условие принятия — простое большинство: «ЗА» > «ПРОТИВ».

Это означает, что злоумышленнику не нужно было получать подавляющее большинство BONK, достаточно было контролировать около 1% эмиссии и получить большинство голосов за свое предложение, чтобы инициировать исполнение.

5. Задержка исполнения Timelock и исполнение в сети (Execution)

Зрелые DAO обычно не исполняют предложение сразу после принятия голосования, а добавляют механизм временной задержки (Timelock): Голосование принято → Ожидание Timelock → Исполнение в сети.

Timelock предоставляет сообществу буферное время, чтобы участники могли:

• Проверить код предложения;
• Выявить потенциальные риски атак;
• Организовать противодействие или инициировать экстренные меры.

После завершения периода ожидания предложение автоматически исполняется фреймворком управления.

Еще одной важной причиной атаки на управление BONK стало отсутствие в его процессе управления стандартного этапа задержки исполнения Timelock: голосование принято → немедленное исполнение.

В инциденте атаки на управление BIP #76 злоумышленник использовал именно отсутствие механизма задержки исполнения в процессе управления BONK, чтобы быстро выполнить злонамеренные действия после принятия предложения.

Заключение

Инцидент с атакой на управление BONK вскрыл давнюю проблему DeFi: Если никто не участвует в управлении, есть ли вообще необходимость в DAO?

Когда управление сообществом превращается в спектакль, действительно ли нужно DAO? На самом деле, низкая активность участия в управлении делает архитектуру DAO скорее неэффективным бременем, чем защитой протокола.

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

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