Разработка системы токен-миграции (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.