Разработка intent-based торгового протокола

Разработка intent-based торгового протокола

Классическая модель DEX: пользователь подписывает транзакцию, которая точно описывает что делать (swap 1 ETH за минимум 3450 USDC через Uniswap V3 пул X). Если рыночные условия изменились — транзакция реверсируется или исполняется по невыгодной цене. Intent-based модель инвертирует это: пользователь подписывает намерение («хочу продать 1 ETH за лучшую возможную цену USDC до 15:00 UTC»), а исполнение делегируется специализированным solver-ам, которые конкурируют за право его выполнить.

Это архитектурный сдвиг, сравнимый с переходом от limit order books к AMM. CoW Protocol, UniswapX, 1inch Fusion — реализации этой идеи с разными trade-off-ами.

Ключевые компоненты системы

Order структура и подпись

Intent — это структурированное сообщение, которое пользователь подписывает через EIP-712. Минимальная структура:

struct Order {
    address maker;          // кто создаёт ордер
    address inputToken;
    address outputToken;
    uint256 inputAmount;
    uint256 minOutputAmount; // минимально приемлемо
    uint256 deadline;        // действителен до
    uint256 nonce;           // защита от replay
    bytes32 partialFillable; // разрешён ли частичный fill
}

EIP-712 типизированная подпись: пользователь видит человекочитаемые данные в MetaMask, не raw hex. Это критично для UX и для защиты от phishing (пользователь понимает что подписывает).

Важный нюанс с nonce: классический инкрементальный nonce не позволяет иметь несколько активных ордеров одновременно. UniswapX использует word + bit схему: 256 ордеров могут быть активны параллельно, каждый бит в uint256 word — один nonce. Отмена ордера = инвалидация бита в on-chain маппинге без отдельной транзакции для каждого ордера.

Solver сеть и конкуренция

Solver — off-chain агент, который мониторит orderbook (обычно off-chain orderbook с on-chain settlement), находит оптимальное исполнение и выполняет его on-chain. Прибыль solver-а — разница между реальной ценой исполнения и minOutputAmount ордера (так называемый surplus).

Архитектурно возможны две модели:

On-chain аукцион (CoW Protocol): batch аукцион, все ордера за период собираются вместе, один winning solver исполняет весь batch. Uniform clearing price — все ордера в batch исполняются по одной цене. Это устраняет front-running внутри batch.

Off-chain первый solver побеждает (UniswapX упрощённо): первый solver, кто исполнил ордер on-chain до deadline — получает reward. Проще, но возможна MEV гонка между solver-ами.

Для кастомного протокола: выбор модели зависит от объёма. При низком объёме batch аукцион не наполняется — нет смысла ждать. При высоком — batch экономит пользователям газ и даёт лучшие цены.

Settlement контракт

Центральный контракт, который:

1. Верифицирует подпись ордера (EIP-712 recovery)
2. Проверяет nonce (не был ли ордер уже исполнен)
3. Проверяет deadline
4. Проверяет что solver передаёт не меньше minOutputAmount
5. Атомарно переводит inputToken от maker к solver и outputToken от solver к maker

function fill(Order calldata order, bytes calldata signature, uint256 fillAmount) external {
    // 1. Recover signer
    address signer = ECDSA.recover(_hashTypedData(order), signature);
    require(signer == order.maker, "Invalid signature");
    
    // 2. Check nonce
    require(!_usedNonces[order.maker][order.nonce], "Nonce used");
    _usedNonces[order.maker][order.nonce] = true;
    
    // 3. Check deadline
    require(block.timestamp <= order.deadline, "Expired");
    
    // 4. Transfer tokens atomically
    IERC20(order.inputToken).safeTransferFrom(order.maker, msg.sender, fillAmount);
    IERC20(order.outputToken).safeTransferFrom(msg.sender, order.maker, outputAmount);
    
    emit OrderFilled(orderHash, msg.sender, fillAmount, outputAmount);
}

Атомарность достигается через safeTransferFrom в обе стороны в одной транзакции. Если solver не одобрил outputToken — вторая transferFrom реверсируется, первая тоже (атомарность EVM).

Permit2 интеграция

Пользователь должен approve settlement контракт для inputToken. Классический approve — отдельная транзакция до первого ордера. С Permit2 (Uniswap) — разрешение подписывается off-chain вместе с ордером, без предварительной on-chain транзакции. Это значимое улучшение UX.

Permit2 поддерживает batch permit — один подписью разрешить несколько токенов. Для протокола с несколькими парами — пользователь один раз approves Permit2 для каждого токена (once per token, not per protocol), дальше все dApps используют Permit2.

Solver реализация

Поиск оптимального исполнения

Solver должен найти лучший маршрут исполнения ордера: через AMM пулы (Uniswap, Curve, Balancer), через CEX (Binance через API, если есть арбитраж), через on-chain orderbooks (Seaport для NFT, clob-based DEX), или через inventory solver-а (если у него есть outputToken).

Алгоритм: запрос котировок от всех источников → выбор лучшей цены → расчёт profitability (outputAmount - minOutputAmount - gas cost - любые fees протокола → прибыль).

Если profit < газ * gasPrice * safetyMultiplier — ордер не берём. Ошибка начинающих solver-ов: брать убыточные ордера в надежде на MEV — это не работает устойчиво.

Защита solver-а от rogue orders

Злоумышленник может создать ордер с inputToken, который при transferFrom вызывает reentrancy в settlement контракт. Или inputToken может быть дефляционным (transfer fee) — solver получает меньше чем ожидал.

Защита settlement контракта: nonReentrant на fill. Defender: solver проверяет inputToken на whitelist известных токенов или проводит simulated fill через eth_call перед реальным исполнением.

Газовая оптимизация

Каждое fill — минимум 2 transfer + signature recovery + nonce check. На mainnet при $50 gas — это $5-15 за транзакцию. При малых ордерах (100 USDC) — неприемлемо.

Решения:

• L2 деплой: Arbitrum One снижает gas в 10-50x, Optimism аналогично
• Batch fill: solver исполняет несколько ордеров в одном batchFill вызове, амортизируя base gas cost
• Calldata оптимизация: abi-encoding ордера оптимизируется под нулевые байты (zero bytes дешевле, 4 gas vs 16 gas). Compact encoding снижает calldata газ на 20-40%

Стек разработки

Solidity 0.8.x + Foundry + OpenZeppelin 5.x. EIP-712 через OpenZeppelin EIP712 abstract contract. Permit2 интеграция через Uniswap/permit2 репозиторий. Off-chain solver: Node.js + TypeScript + ethers.js v6 + viem. Orderbook: собственный сервер или интеграция с существующим (CoW Orderbook API).

Процесс работы

Аналитика (3-5 дней). Выбор модели (batch auction vs first-solver), целевые токены и цепи, требования к solver network (открытая или разрешённая), integration с existing liquidity sources.

Проектирование (5-7 дней). EIP-712 схема ордера, nonce механизм, settlement контракт архитектура, solver reward механизм.

Разработка (6-10 недель). Settlement контракт → Permit2 интеграция → off-chain orderbook → базовый solver → frontend. Каждый компонент тестируется независимо.

Аудит. Settlement контракт управляет пользовательскими средствами напрямую. Внешний аудит обязателен. Особое внимание: EIP-712 signature malleability, reentrancy в fill, корректность nonce invalidation.

Ориентиры по срокам

MVP с базовым settlement и одним solver — 4-6 недель. Production-ready протокол с batch аукционом, открытой solver сетью и оптимизацией газа — 2-3 месяца.

Стоимость рассчитывается после определения модели и scope.