Мультипідписні смарт-контракти: безпека treasury-рішень

Безпечні мультипідписні смарт-контракти: від Safe до кастомних рішень

Уявіть: команда зберігає $3M у treasury, і один скомпрометований Ledger або злитий приватник дозволяє зловмиснику вивести всі кошти. Recovery неможливий. За понад 5 років ми розробили 30+ мультисиг-конфігурацій для протоколів з TVL до $50M. Наш досвід гарантує, що жодна людина в команді не зможе одноосібно вивести treasury, оновити контракт або змінити критичний параметр. Втрати від компрометації одного ключа можуть перевищувати $10M, а повне відновлення репутації часто неможливе. Мультипідписні смарт-контракти — це базовий рівень безпеки для будь-якого DeFi-протоколу, DAO або централізованого проєкту.

Що таке мультисиг і коли він потрібен?

Мультисиг (multisig) — це схема управління криптоактивами, при якій для виконання транзакції потрібно M підписів з N авторизованих учасників (M-of-N). Він обов'язковий, якщо treasury розподілений між засновниками та інвесторами, для зміни параметрів смарт-контракту потрібна згода кількох сторін, або ви хочете захистити протокол від компрометації одного ключа.

Для більшості завдань достатньо Safe (Gnosis Safe) — аудитований контракт з 4+ роками на mainnet, $100B+ під управлінням, підтримкою всіх EVM-мереж. Під капотом — порогова схема M-of-N, офчейн-підписи через EIP-712. Safe зберігає транзакції в ланцюжку, кожен owner підписує структуровані дані, і при наборі M підписів будь-хто може виконати.

Чому Gnosis Safe не завжди достатньо?

Середня вартість розробки кастомного мультисигу становить 3-5 днів роботи інженера, що в перерахунку на капітальні витрати зазвичай дешевше наслідків одного інциденту безпеки.

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

Кастомний мультисиг необхідний, якщо:

• нестандартна логіка авторизації (timelock + multisig + DAO vote)
• on-chain голосування з вагами (weighted multisig)
• специфічні умови виконання (тільки після оракульної події)
• блокчейни без готового Safe: TON, Solana, Aptos

Як ми будуємо захищений мультисиг: покроковий чек-лист

Реалізація мультисигу на Solidity — хрестоматійний матеріал для аудиторів, тому що в ньому регулярно знаходять одні й ті ж класи вразливостей. Ми використовуємо наступний алгоритм перевірки підписів:

function _verifySignatures( bytes32 txHash, bytes[] calldata signatures ) internal view { require(signatures.length >= threshold, "Below threshold"); address lastSigner = address(0); for (uint256 i = 0; i < signatures.length; i++) { address signer = ECDSA.recover(txHash, signatures[i]); require(isOwner[signer], "Not an owner"); require(signer > lastSigner, "Duplicate signer"); // ключова перевірка lastSigner = signer; } } 

Ключові загрози та їх запобігання:

• Replay attack. Контракт приймає список підписів і перевіряє їх. Якщо nonce не включений у підписуваний хеш — та ж транзакція може бути переграна. Правильна структура: keccak256(abi.encode(to, value, data, nonce, chainId)). ChainId обов'язковий — інакше підпис з Ethereum mainnet приймається на Polygon.
• Signature malleability. ECDSA має дві дійсні підписи для одного повідомлення (s і -s mod n). OpenZeppelin ECDSA.recover обробляє це коректно з версії 4.x, перевіряючи s <= secp256k1n / 2. Самописний ecrecover без цієї перевірки допускає дублювання підписів.
• Duplicate signer. Контракт збирає N підписів, перевіряє кожну проти списку owners, але не перевіряє унікальність підписантів. Атака: один owner надає M підписів одного повідомлення — транзакція виконується з M/N = 1 фактичним учасником. Захист: require(signer > lastSigner) з сортуванням адрес.

Як Timelock посилює захист?

Мультисиг 2-of-3 з трьома ключами в одному офісі — не мультисиг у сенсі безпеки. Реальний захист — комбінація мультисигу з TimelockController (OpenZeppelin). Транзакція, підтримана M підписами, ставиться в чергу з затримкою (зазвичай 24-72 години). У цьому вікні community може помітити шкідливу дію. Для протоколів з TVL > $1M TimelockController з затримкою 48 годин — baseline. Параметр minDelay задається при деплої і не може бути зменшений самим timelock-ом (тільки через governance vote або multisig).

Weighted multisig та DAO-інтеграція

Якщо підписанти мають різну вагу (VC фонд з 40% voting power vs окремі контриб'ютори з 5% кожен) — потрібна зважена схема. Реалізуємо через mapping weights[address] і перевірку totalWeight >= requiredWeight замість threshold за кількістю. Інтеграція з Governor (OpenZeppelin) дозволяє будувати гібридні схеми: дрібні операції (до X ETH) — через мультисиг, крупні — через DAO vote з timelock. Кастомний мультисиг з Weighted і Timelock забезпечує захист на 50% краще, ніж звичайний M-of-N.

Multisig на Solana та TON

На Solana використовуємо Squads Protocol — аналог Safe для Solana. Squads v4 підтримує програмовані spending limits, ролі, інтеграцію з Serum/Jupiter. Кастомний мультисиг на Anchor пишемо коли Squads не покриває логіку. На TON — кастомна реалізація на Tact або FunC. TON multisig wallet (офіційний контракт від TON Foundation) підходить для простих випадків зберігання TON. Для jetton-ів та складної логіки — кастомний контракт з обробкою bounce повідомлень.

Що входить у роботу

• Аналіз вимог безпеки та схеми підписів
• Розробка (або кастомізація Safe) під ваш use case
• Написання повного набору unit-тестів (Foundry + fuzzing з Echidna)
• Аудит коду та формальна верифікація — окрема аудиторська перевірка мультисиг контракту
• Деплой скрипти з мультисигом та timelock (Hardhat, Foundry, або Anchor)
• Документація та навчання команди
• Технічна підтримка протягом 2 тижнів після деплою

Строки

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