Разработка протокола кросс-чейн ликвидности

Разработка протокола кросс-чейн ликвидности

Проблема фрагментации ликвидности: $50B в DeFi распределены по десяткам chain. USDC на Arbitrum — это не тот же USDC, что на Optimism. Мост между ними — это не просто «перекидывание токенов», это решение задачи доверия: как сеть A знает, что токены на сети B действительно заблокированы?

Ответов несколько, и каждый — это своя архитектура с разным balancing между security, speed и decentralization. Optimistic bridges, ZK-light client bridges, intent-based bridges, AMM-liquidity bridges — разные трейд-оффы для разных задач.

Архитектурные модели кросс-чейн протоколов

Lock-and-mint vs Liquidity Pool

Lock-and-mint (wrapped assets): токены блокируются на source chain, wrapped копии минтятся на destination. Классика: wBTC (Bitcoin → Ethereum). Проблема: wrapped asset — новый токен с counterparty risk на мост. Если мост взломан — wrapped tokens бесполезны. Так потеряли $320M в Wormhole hack (2022) и $190M в Nomad hack.

Liquidity Pool (native assets): на каждой chain держится пул нативных токенов (USDC on Arbitrum, USDC on Optimism). Пользователь кладёт в пул на source, забирает нативный токен из пула на destination. Это модель Stargate (LayerZero), Across Protocol, Hop Protocol.

Преимущество: пользователь получает настоящий USDC, не wrapped. Недостаток: нужна ликвидность на каждой chain — проблема холодного старта.

Intent-based (solver model): пользователь заявляет намерение ("хочу 1000 USDC на Optimism из моих 1001 USDC на Arbitrum"), solver немедленно выдаёт из своего баланса на destination, позже восстанавливает свой баланс через settlement механизм. Модель Across Protocol (оптимизированная) и UniswapX cross-chain.

Это даёт мгновенный user experience: пользователь видит деньги на destination за секунды, settlement solver-а происходит позже (через bundling и официальный bridge).

Messaging layer: как chain A узнаёт о событии на chain B

Это фундаментальная проблема. Варианты:

Optimistic verification: сообщение принимается как валидное, есть challenge window (30 мин – 7 дней). Если никто не оспорил — считается финальным. Модель: Nomad, Connext Amarok. Плюс: относительно просто. Минус: задержка.

Validator/Oracle set: набор validator-ов наблюдает за source chain и подписывает attestation о событиях. M-of-N multisig разблокирует на destination. Модель: Wormhole (19 guardians), Multichain (MPC nodes), cBridge (SGN validators). Риск: централизованный validator set — основная поверхность атаки.

ZK Light Client: destination chain верифицирует ZK proof о заголовке source chain. Trustless, но технически сложно и дорого по газу. Модели: zkBridge (Polyhedra), Succinct Labs, Herodotus. Технология созревает в 2024–2025.

Native messaging (canonical): Arbitrum bridge, Optimism bridge — используют официальный механизм L1↔L2. Максимально безопасно, но 7-дневный withdrawal delay (fraud proof window для Optimistic rollups).

LayerZero V2: Ultra Light Node (ULN). Две независимые роли: DVN (Decentralized Verifier Network) верифицирует header, Executor доставляет сообщение. Можно настроить набор DVN под требования безопасности. Stargate V2 построен на LayerZero V2.

Глубокий разбор: Stargate / LayerZero архитектура

LayerZero — messaging protocol, Stargate — liquidity protocol поверх него. Разбираем их архитектуру как эталонную реализацию.

LayerZero V2: message flow

Source Chain                                  Destination Chain
┌──────────────────────────────┐             ┌──────────────────────────────┐
│ OApp (User Contract)         │             │ OApp (User Contract)         │
│   ↓ _lzSend()                │             │   ↑ _lzReceive()             │
│ Endpoint                     │             │ Endpoint                     │
│   ↓ emit PacketSent event    │             │   ↑ lzReceive()              │
│                              │             │                              │
│ DVN monitors event           │  DVN signs  │ DVN submits verification     │
│ Executor monitors event ─────┼─────────────→ Executor calls lzReceive()  │
└──────────────────────────────┘             └──────────────────────────────┘

Ключевой инсайт LayerZero V2: OApp (Omnichain Application) — ваш контракт на каждой chain. _lzSend отправляет сообщение через Endpoint. _lzReceive — callback на destination. Всё между ними — задача DVN и Executor.

// OApp базовый контракт (LayerZero V2)
import { OApp, Origin, MessagingFee } from "@layerzerolabs/oapp-evm/contracts/oapp/OApp.sol";

contract CrossChainLiquidityPool is OApp {
    mapping(address => uint256) public deposits;
    
    constructor(address _endpoint, address _owner) OApp(_endpoint, _owner) {}
    
    // Инициирование кросс-чейн депозита
    function depositAndBridge(
        uint32 dstEid,         // destination endpoint ID (chain)
        address recipient,
        uint256 amount,
        bytes calldata extraOptions
    ) external payable {
        // Принимаем токены
        IERC20(depositToken).safeTransferFrom(msg.sender, address(this), amount);
        
        // Кодируем сообщение
        bytes memory message = abi.encode(recipient, amount);
        
        // Рассчитываем fee
        MessagingFee memory fee = _quote(dstEid, message, extraOptions, false);
        require(msg.value >= fee.nativeFee, "Insufficient fee");
        
        // Отправляем кросс-чейн сообщение
        _lzSend(
            dstEid,
            message,
            extraOptions,
            fee,
            payable(msg.sender)
        );
        
        emit DepositBridged(msg.sender, dstEid, recipient, amount);
    }
    
    // Callback на destination chain
    function _lzReceive(
        Origin calldata origin,
        bytes32 /*guid*/,
        bytes calldata payload,
        address /*executor*/,
        bytes calldata /*extraData*/
    ) internal override {
        // Верифицируем source
        require(
            peers[origin.srcEid] == origin.sender,
            "Unknown source"
        );
        
        (address recipient, uint256 amount) = abi.decode(payload, (address, uint256));
        
        // Выплачиваем из пула на destination
        require(poolBalance[depositToken] >= amount, "Insufficient pool");
        poolBalance[depositToken] -= amount;
        IERC20(depositToken).safeTransfer(recipient, amount);
        
        emit BridgeReceived(origin.srcEid, recipient, amount);
    }
}

Stargate V2: Hydra Pool и unified liquidity

Stargate V1 проблема: пул USDC на Arbitrum и пул USDC на Optimism — раздельные. Недобаланс: много выводов из Arbitrum, мало входящих → пул истощается.

Stargate V2 решение — Hydra Pool: единый глобальный пул с кредитными механизмами. Каждый chain имеет credit от глобального пула. Трансферы балансируются глобально, не только между парами chain.

// Упрощённая модель credit-based pool
contract StargatePool {
    // Credits: сколько мы "должны" другим chain пулам
    mapping(uint32 => uint256) public credits; // dstEid => credit
    uint256 public localBalance;
    
    function sendTokens(
        uint32 dstEid,
        address to,
        uint256 amountLD // Local Decimals
    ) external {
        // Конвертируем в Shared Decimals (унифицированная точность)
        uint256 amountSD = _toSD(amountLD);
        
        require(localBalance >= amountSD, "Insufficient balance");
        localBalance -= amountSD;
        
        // Увеличиваем credit для destination (они должны выплатить)
        credits[dstEid] += amountSD;
        
        // Отправляем сообщение через LayerZero
        _sendCrossChain(dstEid, abi.encode(to, amountSD, credits[dstEid]));
    }
    
    // Receive: destination выплачивает и обновляет credits
    function _receiveTokens(uint32 srcEid, address to, uint256 amountSD) internal {
        // Уменьшаем долг перед source
        require(credits[srcEid] >= amountSD, "Insufficient credits");
        credits[srcEid] -= amountSD;
        
        localBalance += amountSD; // будет выплачено пользователю
        IERC20(token).safeTransfer(to, _toLD(amountSD));
    }
}

Shared Decimals — важная деталь: разные chain могут иметь разную точность ERC-20. 6 decimals USDC на Ethereum, 6 на Arbitrum, но потенциально разные. Stargate нормализует к SD (Shared Decimals = 6) для inter-chain учёта.

Rebalancing механизм

Проблема любого liquidity bridge: дисбаланс потоков. Если все выводят из chain A и вводят в chain B — пул на A истощается, на B переполняется.

Automated Rebalancing

contract RebalancingModule {
    // Пороги дисбаланса
    uint256 public constant REBALANCE_THRESHOLD = 20; // 20% отклонение
    uint256 public constant TARGET_UTILIZATION = 80;  // целевой utilization
    
    function checkAndRebalance(uint32 srcEid, uint32 dstEid) external {
        uint256 srcUtilization = getUtilization(srcEid); // % пула использован
        uint256 dstUtilization = getUtilization(dstEid);
        
        if (srcUtilization > TARGET_UTILIZATION + REBALANCE_THRESHOLD &&
            dstUtilization < TARGET_UTILIZATION - REBALANCE_THRESHOLD) {
            
            uint256 rebalanceAmount = calculateRebalanceAmount(srcEid, dstEid);
            _initiateRebalance(srcEid, dstEid, rebalanceAmount);
        }
    }
    
    // LP получают rebalancing incentive за добавление ликвидности в дефицитные пулы
    function rebalancingFeeMultiplier(uint32 chainId) public view returns (uint256) {
        uint256 utilization = getUtilization(chainId);
        if (utilization > 90) return 200; // 2x fee для LP на дефицитной chain
        if (utilization > 75) return 150;
        return 100;
    }
}

Fee механизм для балансировки

Динамический fee: при высоком utilization пула (>80%) — fee для bridge в эту chain растёт. Это экономически стимулирует трансферы в противоположном направлении и добавление ликвидности.

Безопасность: основные векторы атак

Reentrancy через cross-chain callback

Классическая reentrancy усиливается кросс-чейн: атакующий может инициировать повторный вызов через другую chain до завершения первого.

// Защита: статус-машина + nonReentrant
enum BridgeStatus { IDLE, PENDING, COMPLETED }
mapping(bytes32 => BridgeStatus) public transferStatus;

modifier onlyIdle(bytes32 transferId) {
    require(transferStatus[transferId] == BridgeStatus.IDLE, "Not idle");
    transferStatus[transferId] = BridgeStatus.PENDING;
    _;
    transferStatus[transferId] = BridgeStatus.COMPLETED;
}

Oracle/validator manipulation

Если validator set мал или централизован — атака на M-of-N threshold компрометирует весь мост. Wormhole hack: эксплойт в signature verification позволил минтировать 120,000 wETH без backing.

Защиты:

• Использовать проверенные messaging protocols (LayerZero V2, Wormhole, Axelar) вместо своего validator set
• Ввести rate limiting: максимальная сумма bridge за 1 час/24 часа
• Emergency pause: multisig + timelock на критических операциях
• Insurance fund: % от fees идёт в страховой фонд

Replay attack

Одно сообщение не должно быть доставлено дважды. LayerZero защищает через nonce: каждый OApp имеет ordered nonce для каждого src/dst pair. Сообщение с неожиданным nonce отклоняется.

Liquidity provider incentives

Почему кто-то будет держать ликвидность в вашем bridge пуле? Нужна экономическая модель.

Для холодного старта: boosted rewards в первые 3–6 месяцев за счёт протокольной treasury.

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

Смарт-контракты: Solidity 0.8.x + Foundry. Messaging: LayerZero V2 OApp, или Axelar GMP, или Wormhole. Математика: FixedPoint (Uniswap V3 math) для точности. Oracle: Chainlink CCIP Data Feeds для FX курсов.

Backend: Node.js + TypeScript. Monitoring: отслеживание состояния пулов на всех chains, automated rebalancing trigger. Event indexing: The Graph (multi-chain subgraph) или собственный indexer (Ponder).

Frontend: wagmi + viem, multi-chain wallet support.

Этапы разработки

Bridge контракты — одна из самых атакуемых категорий DeFi. Аудит обязателен, идеально — два независимых аудитора. Бюджет аудита: $50k–$200k в зависимости от сложности и аудитора.