Web3 DAO — це псевдопроблема? Глибокий розбір того, чому Bonk зазнав атаки на управління

Автор: Biteye; Джерело: X, @BiteyeCN

Що? Атакуючий може використати 4 мільйони доларів, щоб розкрити казначейство DAO на 20 мільйонів доларів?

Вчора вранці BONK DAO зазнав атаки на управління. Атакуючий використав низький поріг управління 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: Поріг низький, потрібно лише 100M Bonk (425.99 доларів США), що також є причиною атаки на управління Bonk.

2. Етап обговорення спільноти (Governance Forum)

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

• Розкриття плану та збір думок: Дозволяє спільноті заздалегідь ознайомитися зі змістом пропозиції та ставити запитання.

• Оптимізація пропозиції: Коригування параметрів та деталей виконання на основі відгуків для підвищення якості пропозиції.

• Фільтрація низькоякісних пропозицій: Уникнення потрапляння зловмисних або незрілих пропозицій безпосередньо до голосування на ланцюгу.

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

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

3. Snapshot (температурний тест) (Голосування поза ланцюгом)

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

Цей етап зазвичай називають: Temperature Check (температурний тест)

Основні функції:

• Зниження вартості голосування: Голосування поза ланцюгом не вимагає оплати Gas, члени спільноти можуть брати участь з низькими витратами.

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

• Оптимізація напрямку пропозиції: На основі результатів голосування та відгуків спільноти коригувати деталі плану.

Якщо Snapshot (температурний тест) не пройдено, це зазвичай означає, що спільнота не досягла достатнього консенсусу, пропозицію буде припинено або повернено на доопрацювання, і вона не потрапить до етапу офіційного голосування на ланцюгу.

А Bonk DAO саме через відсутність цього важливого захисного запобіжника Snapshot дозволив "злодіям" легко проникнути.

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), тобто: голосів "за" (YES) > голосів "проти" (NO)

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

Вимагається вищий відсоток підтримки, наприклад: 2/3 (близько 66.7%) або більше голосів "за"; або ще вищий відсоток.

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

Іншою важливою причиною атаки на управління BONK є відносно ліберальні параметри управління DAO.

Мінімальний поріг участі вимагає лише 1% від загальної пропозиції права голосу BONK для проведення дійсного голосування. А умови прийняття пропозиції - проста більшість: YES > NO

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

5. Затримка виконання Timelock та виконання на ланцюгу (Execution)

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

Роль Timelock полягає в наданні буферного часу для спільноти, щоб члени могли:

• Перевірити код пропозиції;

• Виявити потенційні ризики атаки;

• Організувати опозицію або вжити екстрених заходів.

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

Важливою причиною атаки на управління Bonk також є відсутність стандартного етапу затримки виконання Timelock у його процесі управління: голосування прийнято → негайне виконання

У випадку атаки на управління BIP #76 атакуючий саме використав відсутність механізму затримки виконання в процесі управління BONK, швидко виконавши зловмисні дії після прийняття пропозиції.

На завершення

Інцидент з атакою на управління BONK виявив давню проблему DeFi: Якщо ніхто не бере участі в управлінні, чи справді DAO потрібне?

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

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

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