Разработка системы токен-миграции (v1 → v2)

Разработка контракта токен-бриджа

Токен-бридж — это инфраструктура, позволяющая перемещать активы между несовместимыми блокчейнами. С точки зрения пользователя всё выглядит просто: заблокировал 100 USDC на Ethereum, получил 100 USDC на Arbitrum. За этой простотой скрывается один из наиболее уязвимых классов смарт-контрактов: Ronin ($625M), Wormhole ($320M), Nomad ($190M) — все взломы произошли именно через мосты.

Это не случайность. Бридж по определению управляет заблокированными активами на одной цепи и выпускает синтетические активы на другой. Взломать bridge = украсть все locked funds сразу. Сложность усиливается тем, что безопасность системы определяется безопасностью cross-chain сообщений — а это принципиально трудная задача.

Архитектурные паттерны

Lock-and-Mint vs Burn-and-Release

Lock-and-Mint: токен блокируется на source chain, на destination chain минтится wrapped версия. Пример: WBTC — BTC заблокирован у кастодиана, ERC-20 WBTC заминчен на Ethereum.

Преимущество: оригинальный токен не требует изменений (не нужна функция burn). Недостаток: ликвидность фрагментирована — wrapped токен на каждой цепи отдельный.

Burn-and-Release: нативный токен сжигается на source chain, разблокируется на destination chain. Требует, чтобы токен имел cross-chain-aware логику или был специально спроектирован (Circle CCTP для USDC использует именно эту модель).

Liquidity pool модель (хаб-и-спок): на каждой цепи пул ликвидности нативного токена. Пользователь депонирует на одной стороне, получает из пула на другой. Так работает Hop Protocol и Across Protocol. Преимущество: нативные токены на обеих сторонах. Недостаток: нужна ликвидность в пулах, иначе бридж не работает.

Для кастомного проекта: если токен ваш и вы контролируете его контракт — Burn-and-Release проще и безопаснее (нет locked funds как цели атаки). Если бриджите чужой токен — Lock-and-Mint.

Модели верификации сообщений

Это ключевой архитектурный выбор. Как destination chain узнаёт, что событие на source chain действительно произошло?

Optimistic верификация (Nomad, Across): сообщение считается валидным если никто не оспорил его за период (обычно 30 минут — несколько часов). Недостаток: latency. Преимущество: дешевле в эксплуатации. Nomad был взломан из-за ошибки в логике оспаривания — доверенное сообщение можно было реплицировать с другим payload.

Multisig верификация (большинство production-мостов): N из M validator-ов подписывают подтверждение события. Wormhole использовал 19 guardians. Уязвимость: компрометация порогового количества ключей. Ronin был взломан именно так — 5 из 9 validator ключей были скомпрометированы.

Light client верификация (zkBridge, IBC): destination chain верифицирует consensus proof source chain. Наиболее безопасно, но дорого по газу. ZK-based верификация (Succinct, =nil; Foundation) позволяет сжать proof, делая это практичным.

Native bridges (Arbitrum, Optimism canonical bridge): используют rollup's own fraud proof или validity proof механизм. Максимально безопасно, но только для конкретной пары L1-L2 и с 7-дневным withdrawal period (optimistic rollups).

Детальная реализация Lock-and-Mint бриджа

Source chain контракт (Locker)

contract BridgeLocker {
    mapping(uint32 => bool) public supportedChains;
    mapping(bytes32 => bool) public processedNonces;
    
    event TokensLocked(
        address indexed token,
        address indexed sender,
        address indexed recipient,
        uint256 amount,
        uint32 destinationChain,
        bytes32 nonce
    );
    
    function lock(
        address token,
        uint256 amount,
        address recipient,
        uint32 destinationChain
    ) external nonReentrant {
        require(supportedChains[destinationChain], "Chain not supported");
        require(amount > 0, "Zero amount");
        
        // Генерируем уникальный nonce для этого transfer
        bytes32 nonce = keccak256(abi.encodePacked(
            block.chainid,
            destinationChain,
            msg.sender,
            recipient,
            token,
            amount,
            block.timestamp,
            blockhash(block.number - 1)
        ));
        
        IERC20(token).safeTransferFrom(msg.sender, address(this), amount);
        
        emit TokensLocked(token, msg.sender, recipient, amount, destinationChain, nonce);
    }
    
    function release(
        address token,
        address recipient,
        uint256 amount,
        bytes32 nonce,
        bytes[] calldata signatures
    ) external {
        require(!processedNonces[nonce], "Already processed");
        require(_verifySignatures(token, recipient, amount, nonce, signatures), "Invalid signatures");
        
        processedNonces[nonce] = true;
        IERC20(token).safeTransfer(recipient, amount);
    }
}

Критичный момент с nonce: он должен быть непредсказуемым и уникальным. Простой счётчик (nonce++) уязвим — атакующий может предвычислить nonce и попытаться replay. Включение blockhash добавляет непредсказуемость.

Destination chain контракт (Minter)

contract BridgeMinter {
    mapping(address => address) public wrappedTokens; // original → wrapped
    mapping(bytes32 => bool) public mintedNonces;
    
    function mint(
        address originalToken,
        address recipient,
        uint256 amount,
        bytes32 nonce,
        bytes[] calldata signatures
    ) external {
        require(!mintedNonces[nonce], "Already minted");
        require(_verifySignatures(originalToken, recipient, amount, nonce, signatures), "Invalid");
        
        mintedNonces[nonce] = true;
        
        address wrapped = wrappedTokens[originalToken];
        if (wrapped == address(0)) {
            wrapped = _deployWrappedToken(originalToken);
            wrappedTokens[originalToken] = wrapped;
        }
        
        IWrappedToken(wrapped).mint(recipient, amount);
        emit TokensMinted(originalToken, wrapped, recipient, amount, nonce);
    }
    
    function burn(
        address wrappedToken,
        uint256 amount,
        address recipient,
        uint32 destinationChain
    ) external nonReentrant {
        IWrappedToken(wrappedToken).burnFrom(msg.sender, amount);
        // emit событие для relayer-ов
        emit TokensBurned(wrappedToken, msg.sender, recipient, amount, destinationChain);
    }
}

Верификация подписей валидаторов

function _verifySignatures(
    address token,
    address recipient,
    uint256 amount,
    bytes32 nonce,
    bytes[] calldata signatures
) internal view returns (bool) {
    require(signatures.length >= threshold, "Not enough signatures");
    
    bytes32 messageHash = keccak256(abi.encodePacked(
        block.chainid,
        token,
        recipient,
        amount,
        nonce
    ));
    bytes32 ethSignedHash = MessageHashUtils.toEthSignedMessageHash(messageHash);
    
    address lastSigner = address(0);
    for (uint256 i = 0; i < signatures.length; i++) {
        address signer = ECDSA.recover(ethSignedHash, signatures[i]);
        require(isValidator[signer], "Not a validator");
        require(signer > lastSigner, "Duplicate signer"); // защита от дублей
        lastSigner = signer;
    }
    return true;
}

Защита от дублирования подписей через сортировку — классический паттерн из Gnosis Safe. Без проверки signer > lastSigner один validator может подписать N раз и пройти threshold.

Relayer инфраструктура

Relayer — off-chain сервис, который мониторит события на source chain и инициирует транзакции на destination chain.

Архитектура надёжного relayer

class BridgeRelayer {
    async watchSourceChain() {
        const filter = lockerContract.filters.TokensLocked();
        
        sourceProvider.on(filter, async (event) => {
            // Ждём подтверждений (finality)
            const receipt = await this.waitForFinality(event.transactionHash);
            
            // Собираем подписи от validator-ов
            const signatures = await this.collectSignatures(event);
            
            // Отправляем на destination chain с retry
            await this.submitWithRetry(event, signatures);
        });
    }
    
    async waitForFinality(txHash: string): Promise<TransactionReceipt> {
        // Для Ethereum: 12 блоков (~2.5 минуты)
        // Для Polygon: 128 блоков (Bor finality)
        // Для Arbitrum: достаточно 1 блока (sequencer finality для L2→L2)
        const CONFIRMATIONS = this.config.requiredConfirmations[this.sourceChainId];
        return await sourceProvider.waitForTransaction(txHash, CONFIRMATIONS);
    }
}

Finality — критический параметр. Ethereum имеет probabilistic finality, но с PoS checkpoint finality каждые ~12 минут. Если relayer отправляет mint до finality source-транзакции, reorg на source chain создаёт ситуацию: mint произошёл, но lock — нет. Так были возможны некоторые атаки в ранних мостах.

Retry и idempotency

Destination chain транзакция может fail: insufficient gas, nonce collision, destination chain congestion. Relayer должен retry с exponential backoff. Idempotency обеспечивается проверкой mintedNonces[nonce] в контракте — повторный mint с тем же nonce отклоняется.

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

1. Replay attack между сетями

Сообщение, валидное для Arbitrum, реплицируется на Optimism. Защита: включить block.chainid (EIP-155) и destinationChainId в подписываемое сообщение.

2. Signature malleability

ECDSA допускает два валидных значения s для одной подписи. OpenZeppelin ECDSA.recover с версии 4.7.3 проверяет s в нижней половине кривой. Никогда не используйте ecrecover напрямую.

3. Reentrancy при release/mint

Если release вызывает safeTransfer до обновления processedNonces — атакующий через callback может повторить вызов. Checks-Effects-Interactions паттерн + nonReentrant обязательны.

4. Validator key compromise

Решение: threshold signature scheme (TSS) вместо обычного multisig. TSS генерирует распределённый ключ — никто не знает полный приватный ключ. Даже при компрометации одного участника ключ не восстановим. Библиотеки: tss-lib (Binance), Silence Laboratories SDK.

5. Infinite mint через upgradeable proxy

Если Minter — upgradeable proxy, upgrade функция должна быть под timelock + multisig. Wormhole Solana exploit был через прямой вызов deprecated функции без проверки.

Тестирование

Foundry идеально подходит для бриджей: fork тесты позволяют работать с реальным state mainnet.

function test_bridgeRoundTrip() public {
    // Fork Ethereum mainnet
    vm.createSelectFork(vm.envString("ETH_RPC"), 19_000_000);
    
    // Симулируем lock на Ethereum
    vm.prank(user);
    locker.lock(USDC, 1000e6, user, ARBITRUM_CHAIN_ID);
    
    // Собираем подписи валидаторов (mock)
    bytes[] memory sigs = _signMessage(messageHash, validatorKeys);
    
    // Переключаемся на Arbitrum fork
    vm.createSelectFork(vm.envString("ARB_RPC"), 180_000_000);
    
    // Минтим на Arbitrum
    minter.mint(USDC_ARB, user, 1000e6, nonce, sigs);
    assertEq(wrappedUSDC.balanceOf(user), 1000e6);
}

Тесты для edge-cases: double-spend через nonce replay, неправильный chain ID в подписи, threshold подписей с дублирующимися адресами.

Стек и сроки

Контракты: Solidity 0.8.x + Foundry + OpenZeppelin 5.x + Hardhat (для multi-chain deploy скриптов). Relayer: TypeScript + viem + BullMQ (очередь задач) + PostgreSQL (хранение pending transfers). Мониторинг: Tenderly для алертов + Grafana для метрик relayer.

Аудит — обязателен. Не как формальность, а как условие деплоя. Минимум один специализированный аудитор с опытом bridge-проектов. Контракт, управляющий заблокированными funds, без аудита — это риск потери всего TVL.

Общий срок от kick-off до mainnet: 3–5 месяцев с учётом аудита. Стоимость рассчитывается после уточнения chain пар, модели верификации и требований к decentralization validator-сети.