Разработка системы децентрализованного страхования
Nexus Mutual потерял 8 миллионов долларов в 2020 году — не из-за взлома, а из-за того, что атакующий манипулировал процессом голосования клеймов. Держатель токенов нарочно голосовал против легитимных выплат, чтобы не допустить dilution своей доли. Это системная проблема дизайна механизма управления, не уязвимость контракта. Децентрализованное страхование — это прежде всего задача mechanism design, и только потом Solidity.
Протокол, который мы проектируем, должен быть устойчив к трём классам атак одновременно: экономическим (манипуляция стейком/голосованием), техническим (reentrancy на клеймах, oracle manipulation) и governance (захват управления через flash loan). Ни один из них не решается «просто написать хороший контракт».
Ключевые механики протокола
Страховой пул и андеррайтинг
Основа — capital pool из средств LP-провайдеров, которые принимают на себя риск в обмен на долю премий. Андеррайтинг конкретного покрытия (например, smart contract exploit на Aave v3) — это создание под-пула с выделенным капиталом и ценообразованием на основе оценки риска.
Ценообразование через модель Poisson: вероятность клейма λ умножается на среднюю сумму выплаты μ. Премия = λ * μ * coverage_amount * duration. Параметры λ обновляются по результатам исторических клеймов — либо вручную governance, либо через on-chain оракул с данными аудитов и инцидентов.
Проблема: если параметры риска хранятся on-chain и обновляются governance, появляется вектор — атакующий может пролоббировать занижение λ для конкретного протокола, скупить дешёвое покрытие, организовать эксплойт, получить выплату. Защита: time lock на обновление параметров риска + мультисиг с разделёнными ключами для критических параметров.
Процесс верификации клейма — самая сложная часть
Три подхода к верификации, каждый с trade-offs:
Optimistic verification (Kleros-стиль). Клейм считается валидным по умолчанию, если никто не оспорил за challenge_period (например, 72 часа). Оспаривание требует стейка от challenger. Если оспорено — идёт арбитраж через Kleros Court или аналог. Быстро и дёшево для неспорных случаев, но уязвимо к «молчаливому majority» — никто не оспаривает, потому что стейкинг риска невыгоден.
Commit-reveal голосование ассессоров. Держатели NXM-аналога стейкают токены, голосуют закрытыми хэшами, раскрывают. Мажоритарная сторона получает reward, меньшинство теряет стейк (Schelling point механика). Требует активного участия сообщества. Подвержен атаке через flash loan: занять токены на голосование, проголосовать, вернуть.
Защита от flash loan в голосовании: snapshot voting — право голоса определяется балансом на блок N, голосование происходит на блоке N+k. Flash loan не работает, потому что токены должны быть в кошельке до события, о котором ещё не известно.
Параметрический триггер (оракул). Выплата происходит автоматически при наступлении on-chain события — например, если цена оракула Chainlink отклонилась >X% за Y блоков, или если TVL протокола упал >50% за 24 часа. Не требует голосования, но покрывает только параметрически описуемые риски. Подходит для depeg coverage, liquidation cascade, bridge exploit с публичными данными.
Мы строим гибридную систему: параметрические триггеры для автоматических мелких клеймов, commit-reveal с защитой от flash loan для крупных.
Capital efficiency через cover tokens
LP провайдер депонирует 100 ETH, получает cvETH — токен, представляющий долю в пуле. cvETH можно использовать в DeFi (стейкинг, коллатерал), пока нет активных клеймов. При активации клейма на сумму X контракт locks соответствующую долю cvETH до завершения процесса верификации. Это устраняет проблему bank run: LP не может вывести средства, пока не разрешены все pending клеймы против его части пула.
Техническая реализация: ERC-4626 vault для capital pool + custom lockShares(address lp, uint256 amount) с контролем доступа только от ClaimsManager контракта.
Storage layout и архитектура контрактов
InsuranceCore (proxy UUPS)
├── CapitalPool (ERC-4626)
├── CoverageManager (создание/управление покрытиями)
├── ClaimsManager (процесс клеймов)
│ ├── ParametricOracle (Chainlink + кастомные триггеры)
│ └── VotingEngine (commit-reveal)
├── PricingEngine (расчёт премий)
└── GovernanceTimelock (изменение параметров)
Proxy UUPS с ERC-7201 namespaced storage — обязательно, потому что протокол будет апгрейдиться. Без namespaced storage первый же апгрейд с добавленной переменной сломает storage layout ClaimsManager.
Типичные уязвимости, которые закрываем
Reentrancy на выплатах. ClaimsManager.processPayout() делает внешний вызов к токен-контракту. Если покрытие номинировано в ERC-777 (с хуком tokensReceived), атакующий может рекурсивно вызвать processPayout до обновления состояния. Решение: nonReentrant + Checks-Effects-Interactions строго, состояние клейма меняется до transfer.
Oracle manipulation через flash loan. Параметрический триггер на цену → атакующий берёт flash loan, роняет цену на DEX, триггер срабатывает, получает выплату, возвращает flash loan. Защита: TWAP от Uniswap v3 вместо spot price, минимальный TWAP период 30 минут. За 30 минут удержать манипулированную цену на mainnet — стоимость атаки превышает потенциальную выплату при любом разумном coverage amount.
Governance takeover. Если управление протоколом через токен-голосование, и токен можно купить/одолжить — governance можно захватить. Стандартное решение: timelock на исполнение proposals (48-72 часа), что даёт сообществу окно для реакции. Для критических параметров — multisig с quorum >50% + timelock. Guardian address с возможностью veto для emergency.
Процесс разработки
Аналитика и mechanism design (1-2 недели). Это самый важный этап. Определяем: какие риски страхуются, как устроен capital pool, механика pricing, полный flow клейма. Пишем формальную спецификацию с инвариантами — «capital pool всегда покрывает не менее 100% active coverage», «клейм не может быть выплачен дважды».
Разработка контрактов (3-4 недели). Solidity + Foundry. Каждый инвариант — это property-based тест в Echidna. Fork-тесты интеграции с Chainlink oracles и Uniswap TWAP на реальных mainnet данных.
Внутренний аудит (1 неделя). Slither, Mythril, ручной review по SWC checklist. Особое внимание: все пути выплат, все точки обновления параметров риска, все места с внешними вызовами.
Внешний аудит (2-4 недели). Для протокола с TVL >500k USD — обязательно. Бюджет на аудит закладывается в проект сразу.
Testnet + bug bounty (1-2 недели). Деплой на Sepolia/Arbitrum Goerli, открытая программа поиска уязвимостей через Immunefi или Code4rena.
Mainnet деплой. Через Gnosis Safe мультисиг. Начальный cap на TVL — «soft launch» с ограниченным покрытием для проверки механик в продакшне.
Ориентиры по срокам
Базовый протокол с параметрическим триггером и простым capital pool — от 4-6 недель. Полная система с голосованием ассессоров, governance, апгрейдаемостью и аудитом — 2-3 месяца. Сроки сильно зависят от сложности mechanism design на входе.
Стоимость рассчитывается после детального обсуждения архитектуры и требований к покрываемым рискам.