Разработка мультичейн-протокола

Разработка мультичейн-протокола

Мультичейн-протокол — это DeFi приложение, которое существует не на одной цепи, а одновременно на 5-20 и более сетях, с общей ликвидностью, единым состоянием и seamless пользовательским опытом. Это сложнее чем просто «задеплоить на несколько цепей»: нужно решить синхронизацию состояния, распределённую ликвидность и согласованный governance.

Паттерны мультичейн-архитектуры

Hub-and-Spoke

Одна «домашняя» цепь (hub) хранит canonical state, остальные — spoke chains, которые синхронизируются с hub.

Примеры: Stargate (Ethereum как hub для liquidity allocation), Wormhole (Solana как hub).

Когда использовать: когда есть ярко выраженная primary chain (обычно Ethereum), и нужны «филиалы» на других цепях.

// Hub контракт — хранит глобальное состояние
contract ProtocolHub {
    // Глобальный TVL по всем цепям
    mapping(uint256 => mapping(address => uint256)) public chainTVL; // chainId -> token -> amount
    
    // Синхронизация от spoke цепей
    function syncFromSpoke(
        uint256 spokeChainId,
        address token,
        uint256 newTvl,
        bytes calldata proof
    ) external onlyBridge {
        require(_verifyProof(spokeChainId, token, newTvl, proof), "Invalid proof");
        chainTVL[spokeChainId][token] = newTvl;
        emit TVLUpdated(spokeChainId, token, newTvl);
    }
    
    // Allocation решение принимается на Hub
    function reallocateLiquidity(
        uint256 fromChain,
        uint256 toChain,
        address token,
        uint256 amount
    ) external onlyGovernance {
        // Инструктируем spoke chains через bridge
        _sendBridgeMessage(fromChain, abi.encode("WITHDRAW", token, amount));
        _sendBridgeMessage(toChain, abi.encode("DEPOSIT", token, amount));
    }
}

Mesh (peer-to-peer)

Все цепи равноправны, каждая общается напрямую с каждой. Более децентрализованно, но O(n²) сложность коммуникации.

Примеры: Connext, Across Protocol.

Когда использовать: для протоколов без явного «центра», когда важна устойчивость к отказу любой цепи.

Shared sequencer

Транзакции из всех цепей поступают в единый sequencer, который упорядочивает их глобально. Подходит для appchains с кастомным execution.

Примеры: Espresso Systems, Astria.

Общая ликвидность

Главная ценность мультичейн-протокола для LP: один депозит обеспечивает ликвидность сразу на всех поддерживаемых цепях. Stargate решил это через Delta Algorithm:

Каждая цепь имеет пул токена X
Пулы связаны: изъятие из пула A компенсируется перебалансировкой из других пулов
LP получают unified receipt token (LP token), которая стоит одинаково на всех цепях

Реализация требует:

1. Accounting module — отслеживает «ideal balance» каждого пула
2. Rebalancing mechanism — восстанавливает баланс через кросс-чейн трансферы
3. Fee structure — комиссии зависят от того, балансирует ли транзакция пулы или дисбалансирует

contract MultichainPool {
    struct PoolInfo {
        uint256 balance;          // текущий реальный баланс
        uint256 idealBalance;     // целевой баланс для ребалансировки
        uint256 deltaCredit;      // накопленный кредит для instant withdrawal
    }
    
    mapping(address => PoolInfo) public pools;
    
    function swap(
        address token,
        uint256 amount,
        uint256 dstChainId,
        address recipient
    ) external {
        PoolInfo storage srcPool = pools[token];
        
        // Рассчитываем комиссию на основе отклонения от ideal balance
        uint256 fee = _calculateFee(srcPool, amount);
        uint256 amountAfterFee = amount - fee;
        
        srcPool.balance += amount;
        
        // Если у destination chain достаточно deltaCredit — instant transfer
        // Иначе — delayed через bridge
        _executeTransfer(dstChainId, token, amountAfterFee, recipient);
    }
}

Мультичейн governance

Governance decisions (смена параметров протокола, добавление новых цепей, распределение treasury) должны быть применены консистентно на всех цепях.

Паттерн: голосование на основной цепи → cross-chain execution:

contract MultichainGovernor {
    // На Ethereum — основной governor
    mapping(bytes32 => Proposal) public proposals;
    
    function executeProposal(bytes32 proposalId) external {
        Proposal storage proposal = proposals[proposalId];
        require(proposal.forVotes > quorumThreshold, "Quorum not reached");
        require(proposal.forVotes > proposal.againstVotes, "Not passed");
        require(block.timestamp > proposal.executionTime, "Timelock active");
        
        proposal.executed = true;
        
        // Исполняем на Ethereum
        _executeLocally(proposal.targets, proposal.calldatas);
        
        // Отправляем execution instructions на все поддерживаемые цепи
        for (uint i = 0; i < supportedChains.length; i++) {
            _sendExecutionToCrossChain(
                supportedChains[i],
                proposal.crossChainTargets[i],
                proposal.crossChainCalldatas[i]
            );
        }
        
        emit ProposalExecuted(proposalId);
    }
}

// На каждой цепи — receiver, исполняющий governance команды
contract GovernanceReceiver {
    address public governor; // адрес governor контракта на home chain
    
    function executeFromGovernor(
        address target,
        bytes calldata calldata_,
        bytes32 proposalId
    ) external onlyBridge {
        // Верифицируем что команда пришла от легитимного governor
        require(_verifyGovernorMessage(proposalId), "Invalid governor");
        
        (bool success, ) = target.call(calldata_);
        require(success, "Execution failed");
        
        emit ProposalExecutedOnChain(proposalId, block.chainid);
    }
}

Мультичейн oracle

Price feeds и данные должны быть консистентны на всех цепях. Варианты:

Chainlink на каждой цепи — стандартный подход, но у малых цепей может не быть Chainlink поддержки.

Push oracle через bridge — главная цепь обновляет цены и рассылает через cross-chain messaging. Риск: задержка и bridge failure.

Pull oracle (Pyth) — каждая цепь независимо получает price update при необходимости от Pyth network. Доступен на 50+ цепях.

Проблема atомарности в мультичейн

Атомарная операция через несколько цепей технически невозможна в классическом смысле (без Byzantine fault tolerant distributed system). Практические подходы:

Optimistic execution: исполняем операцию, если через N минут не пришёл fraud proof — финализируем.

Two-phase commit: prepare → commit/abort. Если любая цепь не может выполнить commit — все цепи делают abort. Дорого по gas, но атомарно.

Compensation transactions: при failure на любой цепи — исполняем compensation (reversal) на всех предыдущих. «Saga» pattern.

Безопасность специфичная для мультичейн

Chain ID spoofing. Контракт должен проверять chainId при replay-sensitive операциях. EIP-155 решает это для транзакций, но для cross-chain сообщений нужно явно.

Bridge liveness dependency. Если bridge не работает — ваш протокол частично недоступен. Нужны fallback механизмы или multi-bridge redundancy.

Inconsistent state. Состояние цепей может расходиться при задержке сообщений. Важно иметь механизм reconvergence и обрабатывать stale state корректно.

Стек

Сроки

• 2 цепи (базовый мультичейн): 6-10 недель
• 5 цепей с unified liquidity: 3-4 месяца
• Мультичейн governance: +4-6 недель
• Security audit: обязателен, 6-10 недель
• Production: 5-7 месяцев