Разработка системы chain abstraction

Разработка системы chain abstraction

Мультичейн реальность DeFi создала UX кошмар: у пользователя ETH на Ethereum, он хочет заплатить на Base, а приложение развёрнуто на Arbitrum. Нужно три шага: bridge ETH на Base, свапнуть на нужный токен, потом снова bridge на Arbitrum. Каждый шаг — отдельное ожидание, отдельные gas fees, отдельный risk.

Chain abstraction — архитектурный подход, при котором приложение и пользователь перестают думать о том, на какой цепи что происходит. Пользователь видит единый баланс, подписывает одну операцию, система сама разбирается с routing, bridging и execution. Near Protocol Foundation продвигает этот термин, но реализации появляются повсюду: NEAR Chain Signatures, Socket Protocol, Particle Network, Agoric Orchestration.

Компоненты системы chain abstraction

1. Unified Account Layer

Пользователь имеет один идентификатор (адрес или DID), который работает на всех цепях. Варианты реализации:

ERC-4337 Smart Account + cross-chain ownership. Smart account на каждой цепи имеет одинаковый адрес (через CREATE2 с одинаковым salt + factory) и одного owner. Ключ на Ethereum = ключ на Arbitrum = ключ на Base.

NEAR Chain Signatures (MPC). NEAR аккаунт может подписывать транзакции для любой внешней цепи — Bitcoin, Ethereum, Cosmos. MPC ноды NEAR сети генерируют подпись для целевой цепи. Пользователь авторизует через NEAR, платит gas в NEAR токенах.

Particle Network Omnichain Account. Объединяет AA и MPC: один master account, кастодированный через MPC, deployable на любую EVM цепь через universal AA.

2. Intent Layer

Вместо явных транзакций пользователь выражает намерение:

interface CrossChainIntent {
    from: {
        chain: 'ethereum'
        asset: 'ETH'
        amount: '1.5'
    }
    to: {
        chain: 'arbitrum'
        asset: 'USDC'
        minAmount: '5000'
    }
    deadline: number
    recipient: string
    // Пользователю не важно как — важен результат
}

Intent routing engine анализирует доступные пути и выбирает оптимальный: через bridge + swap, через агрегатор ликвидности с встроенным bridging (Li.Fi, Socket, Squid), через solver сеть (UniswapX-style cross-chain).

3. Solver / Filler Network

Solvers конкурируют за исполнение cross-chain intent. Solver берёт на себя complexity: он имеет ликвидность на нескольких цепях, может исполнить намерение пользователя немедленно (из собственных средств), затем самостоятельно реконсилирует через bridge.

Это ключевое преимущество: пользователь получает токены на целевой цепи за секунды, не ждёт 15 минут финализации Ethereum. Solver берёт на себя bridge latency risk.

// Упрощённый cross-chain fill механизм
contract CrossChainSettlement {
    struct Fill {
        bytes32 intentHash;    // хэш исходного намерения
        address solver;
        address recipient;
        address outputToken;
        uint256 outputAmount;
        uint32  sourceChain;
        uint256 fillTimestamp;
    }

    mapping(bytes32 => Fill) public fills;

    // Solver исполняет на target chain
    function fill(
        bytes32 intentHash,
        address recipient,
        address outputToken,
        uint256 outputAmount,
        uint32 sourceChain
    ) external {
        IERC20(outputToken).safeTransferFrom(msg.sender, recipient, outputAmount);

        fills[intentHash] = Fill({
            intentHash: intentHash,
            solver: msg.sender,
            recipient: recipient,
            outputToken: outputToken,
            outputAmount: outputAmount,
            sourceChain: sourceChain,
            fillTimestamp: block.timestamp
        });

        emit IntentFilled(intentHash, msg.sender, outputAmount);
    }

    // Solver доказывает fill на source chain и получает возмещение
    function claimReimbursement(bytes32 intentHash, bytes calldata proof) external {
        Fill storage f = fills[intentHash];
        require(f.solver == msg.sender, "Not solver");
        // Верификация proof (cross-chain message от source settlement)
        _verifyAndReimburse(intentHash, proof);
    }
}

4. Cross-chain Message Passing для proof

Чтобы solver получил возмещение на исходной цепи, нужно доказать, что fill произошёл на целевой цепи. Это требует cross-chain messaging: Wormhole, LayerZero, Hyperlane или optimistic fraud proof (через bridge's canonical messaging).

Optimistic approach (Across Protocol): solver получает возмещение оптимистически через 2-4 часа, если никто не оспорил fill. Быстро и дёшево для solver-а.

Cryptographic proof (через ZK или MSG): дороже по gas, но instant finality для solver-а. Применяется в решениях с ZK light clients.

Конкретные протоколы и SDK

Socket Protocol / Bungee

Socket — meta-routing protocol, агрегирует 10+ bridge и DEX протоколов. SDK для frontend:

import { SocketQuote, getQuote, executeRoute } from '@socket.tech/socket-v2-sdk'

const quote = await getQuote({
    fromChainId: 1,              // Ethereum
    fromTokenAddress: ETH_ADDRESS,
    toChainId: 42161,            // Arbitrum
    toTokenAddress: USDC_ADDRESS,
    fromAmount: '1500000000000000000', // 1.5 ETH
    userAddress: userAddress,
    bridgeWithGas: false,
    singleTxOnly: true           // предпочесть single-tx маршруты
})

const route = quote.result.routes[0] // лучший маршрут
const txData = await getRouteTransactionData(route)

// Пользователь подписывает одну транзакцию
await signer.sendTransaction(txData)

Li.Fi SDK

Li.Fi аналогично агрегирует bridges и DEX, но имеет более зрелый SDK и поддержку ERC-4337:

import { LiFi, ChainId, CoinKey } from '@lifi/sdk'

const lifi = new LiFi({ integrator: 'your-app-name' })

const quote = await lifi.getQuote({
    fromChain: ChainId.ETH,
    fromToken: CoinKey.ETH,
    toChain: ChainId.ARB,
    toToken: CoinKey.USDC,
    fromAmount: '1500000000000000000',
    fromAddress: userAddress,
})

// Исполнение с callbacks на каждый шаг
await lifi.executeRoute(signer, quote.route, {
    updateRouteHook: (updatedRoute) => {
        console.log('Step status:', updatedRoute.steps[0].execution?.status)
    }
})

Hyperlane: permissionless cross-chain messaging

Если нужно строить кастомный cross-chain протокол с собственным messaging — Hyperlane позволяет деплоить свою messaging infrastructure на любую EVM цепь. В отличие от Wormhole/LayerZero, можно настроить собственный Interchain Security Module (ISM).

// Hyperlane: отправка сообщения
interface IMailbox {
    function dispatch(
        uint32 destinationDomain,
        bytes32 recipientAddress,
        bytes calldata messageBody
    ) external payable returns (bytes32 messageId);
}

contract ChainAbstractionSource {
    IMailbox mailbox;

    function initiateIntent(CrossChainIntent calldata intent) external payable {
        bytes32 messageId = mailbox.dispatch{value: msg.value}(
            intent.destinationDomain,
            intent.solver,
            abi.encode(intent)
        );
        emit IntentDispatched(messageId, intent.intentHash);
    }
}

Unified Balance View

Чтобы пользователь видел единый баланс, frontend агрегирует данные со всех цепей:

interface UnifiedBalance {
    asset: string
    totalBalance: bigint
    chains: {
        chainId: number
        chainName: string
        balance: bigint
        usdValue: number
    }[]
}

async function getUnifiedBalance(address: string, asset: string): Promise<UnifiedBalance> {
    const chains = [1, 42161, 8453, 10, 137] // ETH, ARB, BASE, OP, POLYGON

    const balances = await Promise.all(
        chains.map(chainId => fetchBalance(address, asset, chainId))
    )

    return {
        asset,
        totalBalance: balances.reduce((sum, b) => sum + b.balance, 0n),
        chains: chains.map((chainId, i) => ({
            chainId,
            chainName: getChainName(chainId),
            balance: balances[i].balance,
            usdValue: balances[i].usdValue,
        }))
    }
}

Для real-time обновлений — WebSocket подписки через Alchemy / Infura на каждую цепь или multicall polling с разумным интервалом (5-10 секунд).

Газовые абстракции

Chain abstraction неполна без решения gas проблемы: у пользователя нет нативного токена на целевой цепи. Варианты:

Gas sponsorship через Paymaster. На целевой цепи Paymaster оплачивает gas из своего баланса. Solver или протокол несёт эти расходы как cost of acquisition.

Gas included в bridge amount. При bridging небольшое количество нативного токена выдаётся пользователю автоматически (gas airdrop). Across Protocol делает это нативно.

ERC-20 gas payment. Через ERC-4337 Paymaster пользователь платит gas в USDC на целевой цепи, даже без ETH.

Мониторинг и UX статусов

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

Initiating... → Source TX confirmed → Bridge in progress (ETA: 5 min) → Destination TX confirmed ✓

Для мониторинга: Socket/Li.Fi предоставляют status API по txHash. Wormholescan для Wormhole маршрутов. Кастомный polling backend с WebSocket → frontend push.

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

Процесс разработки

Аналитика и дизайн (1 неделя). Выбор: агрегация через готовые SDK (Li.Fi/Socket) vs кастомный solver protocol. Целевые цепи, токены, UX требования, газовая модель.

Backend и routing (2-3 недели). Intent routing engine, solver logic (если кастомный), cross-chain messaging интеграция, status monitoring.

Smart contracts (2-3 недели). Settlement контракты на каждой цепи, cross-chain proof механизм, Paymaster для gas abstraction. Аудит обязателен.

Frontend и unified UX (2-3 недели). Unified balance view, intent builder UI, cross-chain status tracker, gas estimation.

Тестирование и launch (1-2 недели). End-to-end тестирование на testnets, load testing solver, monitoring setup.

Решение на базе Li.Fi/Socket SDK без кастомных контрактов — 4-6 недель. Полностью кастомный solver protocol с cross-chain messaging — 3-5 месяцев.