Разработка протокола стабильного обмена
Curve Finance держит $3-5 млрд TVL не потому что первая DEX, а потому что решила конкретную математическую проблему: Uniswap V2 с x*y=k кривой даёт 1% slippage уже при обмене 0.1% от пула. Для активов, которые должны стоить одинаково (USDC/USDT, stETH/ETH, WBTC/renBTC), это неприемлемо. Stable swap инвариант концентрирует ликвидность вокруг паритета и снижает slippage на порядки.
Если ваш проект работает с pegged активами — LST (liquid staking tokens), стейблкоины, wrapped assets — вам нужна именно эта математика.
Математика stable swap: почему это не просто «AMM для стейблкоинов»
StableSwap инвариант Curve
Curve использует гибридный инвариант, комбинирующий constant sum (x+y=k, нулевой slippage) и constant product (x*y=k, бесконечная ликвидность). Формула для двух активов:
A * n^n * sum(x_i) + D = A * D * n^n + D^(n+1) / (n^n * prod(x_i))
где A — amplification coefficient, D — инвариант, n — количество активов.
Amplification coefficient — ключевой параметр. При A=0 система ведёт себя как Uniswap (constant product). При A→∞ — как constant sum. Curve использует A=100-2000 в зависимости от пула. Для пар типа USDC/USDT — высокий A (100-200), потому что активы редко отклоняются от паритета. Для stETH/ETH на старте — ниже, потому что stETH торговался с дисконтом и высокий A привёл бы к дисбалансу пула.
Важно: A можно менять. Но изменение A должно быть градуальным — Curve реализует ramp_A/stop_ramp_A с таймлоком минимум 7 дней и ограничением изменения не более чем в 10x за раз. Резкое изменение A при несбалансированном пуле — это фактически изменение цены активов, что эквивалентно манипуляции.
Решение D через итерации Ньютона
Уравнение инварианта не имеет аналитического решения относительно D — используется метод Ньютона-Рафсона. Типичная имплементация сходится за 4-8 итераций при нормальных балансах. Проблема: при сильно несбалансированном пуле или экстремальных значениях итерации могут не сходиться.
В Solidity это выглядит как цикл с ограничением на 255 итераций и проверкой |D_new - D_prev| <= 1. Если не сошлось — revert. Это редкий кейс, но без него контракт может зависнуть в infinite loop при атаке специально подобранными параметрами.
Точность вычислений и PRECISION_MUL
Разные стейблкоины имеют разные decimals: USDC — 6, DAI — 18, USDT — 6. Внутри контракта все балансы нормализуются до 18 decimals через PRECISION_MUL = [1e12, 1e12, 1] (для пула USDC/USDT/DAI). Забыть эту нормализацию — значит получить арифметическую уязвимость, которая позволяет вытащить из пула несправедливую долю активов через remove_liquidity_one_coin.
Реальный кейс: именно ошибка в нормализации decimals стала одним из векторов в нескольких форках Curve, где атакующий мог извлечь больше токенов с 18 decimals, чем вносил токенов с 6 decimals.
Что строим: компоненты протокола
Базовый пул (2-3 актива)
Контракт хранит балансы, реализует exchange(), add_liquidity(), remove_liquidity(), remove_liquidity_one_coin(). LP-токен — ERC-20 с mintом при добавлении ликвидности. Комиссия (обычно 0.04%) делится между LP и protocol fee.
get_dy() (view функция расчёта output) должна реплицировать логику exchange() с точностью до 1 wei. Если есть расхождение — арбитражники будут использовать разницу.
Meta-pool архитектура
Curve использует meta-pools для пар типа newStable/3CRV. Новый стейблкоин пулится не с тремя активами напрямую, а с LP-токеном базового 3pool. Это:
- Снижает фрагментацию ликвидности
- Даёт доступ ко всей ликвидности 3pool через одну торговую пару
Имплементация сложнее: exchange_underlying() должен разворачивать вложенный LP-токен в базовые активы. Математика остаётся той же, но появляются дополнительные вызовы к базовому пулу.
Rate providers для non-pegged активов (Curve V2 / Balancer-style)
stETH/ETH не торгуется ровно 1:1 — stETH накапливает yield. Нужен rate provider: контракт, который возвращает текущий обменный курс. Пул использует rate при расчёте инварианта, что позволяет торговать без slippage даже когда активы не 1:1.
Это критически важная точка: если rate provider манипулируем (например, использует spot price из пула) — вся математика пула становится эксплуатируемой. Rate provider должен использовать внешний trusted oracle или накопленный rate (как stETH/ETH из Lido контракта), не зависящий от текущих торгов.
Стек и инструменты
Solidity 0.8.x для основных контрактов. Для математики с высокой точностью используем mulDiv из OpenZeppelin Math — избегаем переполнения при промежуточных вычислениях типа a * b / c где a * b может превысить uint256.
Foundry для тестирования: fork-тесты на Ethereum mainnet позволяют воспроизвести реальные балансы Curve пулов и сравнивать output нашего контракта с оригиналом. Расхождение больше 1 wei на тех же входных данных — красный флаг.
Vyper (как Curve) vs Solidity: оригинальный Curve написан на Vyper. Мы пишем на Solidity для лучшей совместимости с toolchain (Foundry, Slither, Hardhat-экосистема). Математика — идентична при правильной имплементации.
| Компонент | Инструмент | Причина |
|---|---|---|
| Контракты | Solidity 0.8.x | Toolchain совместимость |
| Математика | OpenZeppelin Math.mulDiv | Overflow-safe |
| Тесты | Foundry + fork mainnet | Сравнение с Curve оригиналом |
| Статический анализ | Slither + Aderyn | Выявление арифметических проблем |
| Фуззинг | Echidna | Инварианты D-константы |
Риски при форке Curve
Форкнуть Curve — соблазнительно, код открытый. Но:
Vyper→Solidity трансляция содержит ловушки. В Vyper @view функции не могут изменять состояние на уровне компилятора. В Solidity за этим следит только view модификатор, который не всегда применяется корректно при трансляции.
Reentrancy в read-only контексте: атака read-only reentrancy на Curve (2023) позволила манипулировать ценой в LP-токене через вызов во время remove_liquidity. Протоколы, использующие цену LP-токена Curve как oracle, были уязвимы. Если ваш пул планируется как oracle для других протоколов — реализуйте reentrancy lock на все state-changing функции и отдельный view-safe price feed.
Процесс работы
Спецификация (1 неделя). Определяем: количество активов, нужны ли rate providers, архитектура (базовый пул vs meta-pool), модель сборов, governance параметры (кто может менять A и комиссию).
Разработка математического ядра (1-2 недели). Инвариант, Newton's method для D, get_y() для расчёта выхода. Покрытие тестами: сравнение с Python reference implementation Curve.
Контракты пула и LP-токена (1-2 недели). exchange, add/remove liquidity, admin functions с timelock.
Интеграционные тесты (1 неделя). Fork-тесты, fuzzing инвариантов, stress testing extreme imbalance сценариев.
Аудит. Для пулов с реальными средствами — обязателен внешний аудит. Математика stable swap нетривиальна и содержит неочевидные edge cases.
Сроки: 2-3 месяца от спецификации до готовности к аудиту. Зависит от сложности архитектуры (базовый пул vs meta-pool с rate providers). Стоимость — после финализации требований.