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

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

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

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

Оценим ваш проект за 2–3 дня. Пишите — обсудим детали.

Почему бриджи так уязвимы?

Бридж управляет ликвидностью на нескольких цепях. Атакующие эксплуатируют компрометацию валидаторов (Ronin), ошибки в логике оспаривания (Nomad), или реплей-атаки через неправильную подпись сообщения. Каждый из этих векторов перекрывается на этапе проектирования: мы используем threshold signature scheme (TSS) для защиты ключей, nonce с blockhash фидом для уникальности и обязательные аудиты как условие деплоя.

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

Lock-and-Mint vs Burn-and-Release vs Liquidity Pool — разработка системы токен

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 использует именно эту модель. Для кастомного проекта, где ваш токен и вы контролируете контракт, Burn-and-Release проще и безопаснее (нет locked funds как цели атаки).

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

Как обеспечить безопасность верификации сообщений?

Верификация — ключевой архитектурный выбор. Как destination chain узнаёт, что событие на source chain действительно произошло? Используется один из подходов:

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

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

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. Максимально безопасно, но только для конкретной пары L1-L2 и с 7-дневным withdrawal period.

Детальная реализация 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);
    }
}

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;
}

Relayer инфраструктура и мониторинг

Relayer — off-chain сервис, мониторящий события на source chain и инициирующий транзакции на destination chain. Мы реализуем его на TypeScript + viem + BullMQ для очередей. Критический параметр — finality. Ethereum требует 12 блоков (~2.5 минуты), Polygon — 128 блоков. Если relayer отправляет mint до finality, reorg на source chain создаёт дисбаланс: mint произошёл, а lock — нет. Наш relayer ожидает checkpoint finality и использует idempotency через nonce.

Дополнительно настраиваем Tenderly для алертов и Grafana для метрик (задержки, ошибки, количество pending).

Что входит в работу

• Проектирование архитектуры (выбор модели верификации, chain pair)
• Разработка контрактов Locker/Minter с тестами (unit + fork на Foundry)
• Разработка Relayer-сервиса с retry и мониторингом
• Развёртывание и конфигурация валидаторов (TSS или multisig)
• Интеграция с кошельками и фронтендом (ethers.js, RainbowKit)
• Внешний аудит контрактов (организация и исправление находок)
• Документация и обучение команды
• Гарантия на контракты после аудита

Сроки и стоимость

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

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

1. Анализ требований — фиксируем цепочки, токены, модель управления валидаторами.
2. Проектирование — выбираем архитектуру (lock-and-mint, burn-and-release, или LP) и механизм верификации.
3. Разработка — пишем контракты и relayer, пишем fork-тесты с реальным mainnet state.
4. Тестирование — run тестов с форками mainnet, симуляция атак (replay, malleability, reentrancy).
5. Аудит — передача кода внешним аудиторам, устранение находок.
6. Деплой — развёртывание на mainnet, мониторинг первых транзакций.

Закажите разработку моста под ключ — мы проведём весь цикл от идеи до mainnet.