Разработка контракта токен-бриджа
Токен-бридж — инфраструктура для перемещения активов между несовместимыми блокчейнами. С точки зрения пользователя всё выглядит просто: заблокировал 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. Преимущество: нативные токены на обеих сторонах. Недостаток: требуется ликвидность в пулах.
| Модель | Требование к токену | Риск locked funds | Использование в production |
|---|---|---|---|
| Lock-and-Mint | Любой ERC-20 | Высокий | WBTC, Polygon Bridge |
| Burn-and-Release | Наличие burn() | Низкий | Circle CCTP, Arbitrum BRIDGE |
| Liquidity Pool | Любой ERC-20 | Средний (ликвидность) | Hop, Across |
Как обеспечить безопасность верификации сообщений?
Верификация — ключевой архитектурный выбор. Как 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.
| Модель верификации | Безопасность | Затраты газа | Latency | Пример |
|---|---|---|---|---|
| Optimistic | Средняя | Низкие | 30 мин — 2 ч | Across |
| Multisig | Высокая (при TSS) | Средние | Минуты | Wormhole |
| Light client | Очень высокая | Высокие | Минуты | zkBridge |
| Native L2 | Максимальная | Низкие | ~7 дней | Arbitrum Bridge |
Детальная реализация 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)
- Внешний аудит контрактов (организация и исправление находок)
- Документация и обучение команды
- Гарантия на контракты после аудита
Сроки и стоимость
| Компонент | Сложность | Срок |
|---|---|---|
| Locker + Minter контракты | Высокая | 2–3 недели |
| Signature verification | Средняя | 1 неделя |
| Relayer сервис | Высокая | 2–3 недели |
| Wrapped token factory | Низкая | 3–5 дней |
| Тесты (unit + fork) | Высокая | 2 недели |
| Аудит (внешний) | — | 3–6 недель |
Общий срок от kick-off до mainnet: 3–5 месяцев с учётом аудита. Стоимость рассчитывается индивидуально после уточнения chain пар, модели верификации и требований к decentralization. Оценим ваш проект за 2–3 дня — свяжитесь с нами.
Процесс работы
- Анализ требований — фиксируем цепочки, токены, модель управления валидаторами.
- Проектирование — выбираем архитектуру (lock-and-mint, burn-and-release, или LP) и механизм верификации.
- Разработка — пишем контракты и relayer, пишем fork-тесты с реальным mainnet state.
- Тестирование — run тестов с форками mainnet, симуляция атак (replay, malleability, reentrancy).
- Аудит — передача кода внешним аудиторам, устранение находок.
- Деплой — развёртывание на mainnet, мониторинг первых транзакций.
Закажите разработку моста под ключ — мы проведём весь цикл от идеи до mainnet.