Безопасные мультиподписные смарт-контракты: разработка 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 недель после деплоя

Сроки

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