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

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

Ronin Bridge втратив $625M у березні 2022 року — 5 з 9 validator keys були скомпрометовані. Sky Mavis тримала 4 ключі в одному місці «для зручності». Мультисиг був, поріг був. Але фізична ізоляція ключів — ні. Технічно правильна система мультисиг-управління вимагає правильного протоколу зберігання ключів не менше, ніж правильного смарт-контракту.

Це важливо розуміти до початку розробки: контракт — одна частина. Друга — організаційні процедури навколо нього.

Gnosis Safe як основа

Safe (раніше Gnosis Safe) — стандарт де-факто для мультисиг-управління у Web3. Використовується Uniswap DAO, Aave, Lido, ENS та сотнями інших протоколів. Аудирований багато разів, open source, модульна архітектура.

Чому Safe, а не кастомний контракт: 3+ років у production на сумах >$100B TVL — це аргумент важчий за будь-який аудит нового контракту. Кастомний мультисиг розробляємо тільки при явних обмеженнях: non-EVM ланцюг, нестандартна логіка квум, вимоги до privacy.

Архітектура Safe

Safe працює за схемою M-of-N: транзакція виконується, коли зібрав M підписів з N власників. Під капотом — execTransaction() з масивом підписів ECDSA в упорядкованому вигляді. Підписи можна збирати off-chain (через Safe{Wallet}) або on-chain через approveHash().

// Формат підпису для Safe
// r (32 bytes) + s (32 bytes) + v (1 byte)
// v=1: approved hash on-chain
// v=2: eth_sign signature
// v>30: EIP-1271 contract signature

Safe Modules: розширення без кастомного контракту

Модулі — це окремі контракти з правом викликати execTransactionFromModule() на Safe. Це дозволяє додати автоматизацію (наприклад, щодня виплачувати до ліміту X без мультисиг) без змін основного контракту.

Стандартні модулі: Allowance Module (делегує право на видатки до ліміту), Safe{Recovery Module} (соціальне відновлення доступу). Кастомні модулі розробляємо під специфіку клієнта.

Головний ризик модулів: модуль з уязвимістю обходить весь мультисиг. Будь-який кастомний модуль потребує аудиту з тією ж серйозністю, що й сам контракт казначейства.

Коли потрібен кастомний мультисиг

Три випадки з практики:

Нестандартні правила квум. Протокол хоче: 2/5 підписів для транзакцій до $10k, 4/5 для $10k-$1M, 5/5 для >$1M. Safe не підтримує динамічний threshold. Рішення — Safe + кастомний guard (SafeGuard), який перевіряє суму транзакції та вимагає додаткові підписи.

On-chain голосування по транзакціях. Якщо рішення повинні проходити через токен-голосування (snapshot + виконання через мультисиг), стандартний Safe + Governor + Timelock працює. Якщо потрібна схема делегованого голосування з зважованими голосами — кастомна інтеграція.

Non-EVM ланцюги. Для Solana — програма на Anchor з логікою M-of-N через secp256k1 верифікацію або нативні multisig accounts. Для Aptos/Sui — кастомні Move-модулі.

Safe Guards: додатковий рівень контролю

Safe Guard — контракт, який викликається до та після кожної транзакції Safe. Дозволяє додати обмеження без змін основного Safe:

• Whitelist дозволених адрес-отримувачів
• Ліміти на суму транзакції
• Time-based обмеження (немає транзакцій у вихідні — для regulated протоколів)
• Блокування зміни owners без додаткового узгодження

interface Guard {
    function checkTransaction(
        address to, uint256 value, bytes calldata data,
        Enum.Operation operation, uint256 safeTxGas,
        uint256 baseGas, uint256 gasPrice, address gasToken,
        address payable refundReceiver, bytes memory signatures,
        address msgSender
    ) external;

    function checkAfterExecution(bytes32 txHash, bool success) external;
}

Організаційні вимоги до системи

Технічно правильний мультисиг з поганим управлінням ключами — це ілюзія безпеки. Мінімальні вимоги:

• Ключі у hardware wallets (Ledger, Trezor), не у hot wallets
• Географічне розподілення підписантів
• Задокументований процес заміни скомпрометованого ключа
• Регулярна перевірка, що всі підписанти мають доступ до своїх ключів
• Timelock поверх мультисига для критичних операцій

Ми допомагаємо не тільки з технічним деплоєм, але й з розробкою операційних процедур.

Процес та строки

Вартість розраховується індивідуально після описання вимог до управління: кількість signers, типи операцій, вимоги до автоматизації.