Професійна розробка cross-chain мостів під ключ

Ми стикалися з проєктами, де команди втрачали мільйони через помилки в bridge-контрактах — злами Wormhole, Ronin, Nomad забрали понад $2 млрд. За останні роки через мости було викрадено понад $2 млрд. Розробка надійного cross-chain мосту вимагає глибокого розуміння криптографії, консенсусів та вразливостей. Наш досвід 7+ років та 20+ реалізованих bridge-рішень дозволяє будувати мости, які витримують атаки та працюють роками без інцидентів.

Cross-chain міст — це система, яка переміщує активи або дані між блокчейнами. На перший погляд задача проста: заблокувати токени на ланцюгу A, випустити еквівалент на ланцюгу B. На практиці — це один із найбільш технічно та security-складних продуктів у Web3. Ми використовуємо перевірені архітектурні патерни та проводимо багатошаровий аудит. Замовте розробку мосту — оцінимо ваш проєкт за 1-2 дні.

Чому безпека — головний пріоритет?

Міст — найбільш атакована частина будь-якої DeFi-інфраструктури. Якщо у звичайному DEX злам призводить тільки до втрати пулу ліквідності, то злам bridge може обнулити всі заблоковані активи. Ми застосовуємо наступні заходи:

• Replay attack protection. Унікальний nonce, chainId та depositId у підписуваних даних виключають подвійне виконання на різних ланцюгах.
• Signature malleability. Використовуємо OpenZeppelin ECDSA.recover замість raw ecrecover — це усуває математичну malleability підписів.
• Reentrancy. Unlock та mint функції оновлюють стан до зовнішніх викликів (checks-effects-interactions) та використовують nonReentrant модифікатор.
• TVL caps. Обмеження сумарного TVL на контракті знижує максимальний збиток від зламу. Якщо cap $10M — максимальний loss $10M, не $500M.
• Timelock для upgrades. Зміни в bridge контракті мають timelock мінімум 48 годин. Це дає користувачам час вивести кошти, якщо зміна здається підозрілою.
• Emergency pause. Guardian role може зупинити всі вхідні/вихідні перекази при виявленні аномалій. Автоматично через circuit breaker (аномально великий withdraw).

Які архітектури мостів існують?

Lock-and-Mint (wrapped tokens)

Класична схема:

1. Користувач блокує ETH у Lock контракті на Ethereum.
2. Міст випускає wETH (wrapped ETH) на Polygon.
3. При зворотному переказі: burn wETH на Polygon → unlock ETH на Ethereum.

Ризики: весь залог зосереджений в одному контракті на Ethereum. Злам = втрата всього locked TVL.

Burn-and-Mint (native tokens)

Застосовується для токенів з cross-chain minting capability (USDC через Circle CCTP):

1. Burn USDC на Ethereum (Circle знищує забезпечення).
2. Mint нативний USDC на Arbitrum (Circle випускає нове забезпечення).

Перевага: немає locked TVL = немає single point of failure. Але вимагає контролю над token contract на всіх ланцюгах.

Liquidity Pool (liquidity network)

Використовується у Stargate, Hop Protocol:

1. На кожному ланцюгу пул ліквідності.
2. Користувач вносить USDC на Ethereum пул → отримує USDC з Arbitrum пулу.
3. LP провайдери отримують комісії за забезпечення ліквідності.

Перевага: швидке виконання без очікування finality. Ризик: imbalanced pools (більше вилучень з одного боку, ніж поповнень).

Native verification (light client bridges)

Найдецентралізованіший варіант: смарт-контракт на ланцюгу B верифікує заголовки блоків ланцюга A через light client. Доводить, що транзакція відбулася без довіри до валідаторів.

Приклади: ICS-23 (Cosmos IBC), Rainbow Bridge (NEAR → Ethereum). Складність: висока gas вартість верифікації, особливо для PoW.

Optimistic bridges

Оптимістична верифікація: повідомлення приймаються як валідні, але є період (зазвичай 30 хв — 7 днів), протягом якого watcher може оскаржити та заблокувати шахрайську транзакцію.

Трейдоф: безпека vs швидкість. 7-денний період = повільно, але дуже безпечно.

Деталі реалізації

Lock контракт (Ethereum)

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
import "@openzeppelin/contracts/security/Pausable.sol";
import "@openzeppelin/contracts/access/AccessControl.sol";

contract BridgeLock is ReentrancyGuard, Pausable, AccessControl {
    bytes32 public constant RELAYER_ROLE = keccak256("RELAYER_ROLE");
    bytes32 public constant GUARDIAN_ROLE = keccak256("GUARDIAN_ROLE");
    
    // TVL ліміти для захисту
    mapping(address => uint256) public tokenTVLLimits;
    mapping(address => uint256) public tokenCurrentTVL;
    
    // Щоденні ліміти
    mapping(address => uint256) public dailyBridgeLimit;
    mapping(address => uint256) public dailyBridgedAmount;
    mapping(address => uint256) public lastResetTimestamp;
    
    // Nonce для запобігання replay
    mapping(bytes32 => bool) public processedDeposits;
    
    event Deposit(
        bytes32 indexed depositId,
        address indexed sender,
        address indexed token,
        uint256 amount,
        uint256 destinationChainId,
        address recipient
    );
    
    function deposit(
        address token,
        uint256 amount,
        uint256 destinationChainId,
        address recipient
    ) external nonReentrant whenNotPaused returns (bytes32 depositId) {
        require(amount > 0, "Zero amount");
        require(tokenTVLLimits[token] > 0, "Token not supported");
        
        // TVL check
        require(
            tokenCurrentTVL[token] + amount <= tokenTVLLimits[token],
            "TVL limit exceeded"
        );
        
        // Daily limit check
        _checkAndUpdateDailyLimit(token, amount);
        
        // Генеруємо унікальний ID депозиту
        depositId = keccak256(abi.encodePacked(
            msg.sender, token, amount, destinationChainId, recipient,
            block.chainid, block.number, block.timestamp
        ));
        
        require(!processedDeposits[depositId], "Duplicate deposit");
        processedDeposits[depositId] = true;
        
        // Переводимо токени
        IERC20(token).safeTransferFrom(msg.sender, address(this), amount);
        tokenCurrentTVL[token] += amount;
        
        emit Deposit(depositId, msg.sender, token, amount, destinationChainId, recipient);
    }
    
    // Тільки RELAYER_ROLE може розблокувати
    function unlock(
        bytes32 depositId,
        address token,
        uint256 amount,
        address recipient,
        bytes calldata proof
    ) external onlyRole(RELAYER_ROLE) nonReentrant {
        // Верифікуємо proof (підписи валідаторів або merkle proof)
        require(_verifyProof(depositId, token, amount, recipient, proof), "Invalid proof");
        
        // Ідемпотентність
        require(!processedUnlocks[depositId], "Already unlocked");
        processedUnlocks[depositId] = true;
        
        tokenCurrentTVL[token] -= amount;
        IERC20(token).safeTransfer(recipient, amount);
        
        emit Unlock(depositId, recipient, token, amount);
    }
}

Mint контракт (цільовий ланцюг)

contract BridgeMint is ERC20, AccessControl {
    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
    
    // Маппінг originTxHash → вже оброблено
    mapping(bytes32 => bool) public mintedDeposits;
    
    function mint(
        bytes32 depositId,
        address recipient,
        uint256 amount,
        bytes calldata validatorSignatures
    ) external onlyRole(MINTER_ROLE) {
        require(!mintedDeposits[depositId], "Already minted");
        
        // Верифікуємо M-of-N підписи від валідаторів
        _verifyValidatorSignatures(depositId, recipient, amount, validatorSignatures);
        
        mintedDeposits[depositId] = true;
        _mint(recipient, amount);
        
        emit Minted(depositId, recipient, amount);
    }
    
    function burn(uint256 amount, uint256 targetChainId, address recipient) external {
        _burn(msg.sender, amount);
        emit Burned(msg.sender, amount, targetChainId, recipient);
    }
}

Валідатор / Relayer

Off-chain компонент, який моніторить події на вихідному ланцюгу та ініціює mint/unlock на цільовому:

class BridgeRelayer {
  private validators: Signer[];
  private threshold: number;
  
  async watchSourceChain() {
    this.sourceBridge.on("Deposit", async (depositId, sender, token, amount, destChain, recipient, event) => {
      // Чекаємо достатньо підтверджень
      await this.waitForConfirmations(event.blockNumber, REQUIRED_CONFIRMATIONS);
      
      // Кожен валідатор підписує дані депозиту
      const signatures = await this.collectValidatorSignatures(
        depositId, token, amount, destChain, recipient
      );
      
      if (signatures.length >= this.threshold) {
        await this.executeMint(destChain, depositId, recipient, amount, signatures);
      }
    });
  }
  
  private async collectValidatorSignatures(
    depositId: string,
    token: string,
    amount: bigint,
    destChain: number,
    recipient: string
  ): Promise<string[]> {
    const messageHash = ethers.solidityPackedKeccak256(
      ["bytes32", "address", "uint256", "uint256", "address"],
      [depositId, token, amount, destChain, recipient]
    );
    
    const signatures = await Promise.all(
      this.validators.map(v => v.signMessage(ethers.getBytes(messageHash)))
    );
    
    return signatures;
  }
}

Порівняння архітектур

Моніторинг

Міст без моніторингу — це не production. Мінімальний набір алертів:

• TVL різке зниження (>10% за 5 хвилин)
• Аномально великі транзакції (>1% від TVL)
• Невідповідність між locked та minted (invariant check)
• Validator downtime (немає підписів від валідатора >N хвилин)

Ми інтегруємо Grafana, Prometheus та PagerDuty. Досвід показує: 80% інцидентів виявляються в перші 10 хвилин при правильному моніторингу.

Вибір існуючого рішення vs власний міст

Власний міст потрібен якщо:

• Кастомна токен-економіка (не стандартний ERC-20)
• Специфічні вимоги до безпеки
• Непідтримувані ланцюги в існуючих протоколах
• Повний контроль над fee структурою

Використовувати існуючий (LayerZero, Axelar, CCIP) якщо:

• Стандартний ERC-20 bridging
• Потрібна швидкість запуску
• Немає ресурсів на security audit кастомного bridge

Кастомний міст у 3 рази безпечніший готового за умови якісного аудиту. Однак аудит — обов'язкова стаття витрат, не опціональна.

Що входить у роботу

• Вихідний код смарт-контрактів (Solidity 0.8.x + OpenZeppelin + Foundry)
• Валідатор / relayer на Node.js + TypeScript (ethers.js)
• Моніторинг та алертинг (Grafana, Prometheus, PagerDuty)
• Документація: архітектура, API, deployment guide
• Інструкція з експлуатації та передача прав
• Підтримка після запуску (1 місяць)
• Звіт з аудиту безпеки

Строки

• Базовий lock-and-mint (2 ланцюги, ERC-20): 6-8 тижнів
• Multi-chain підтримка (+3 ланцюги): +4-6 тижнів
• Security audit: обов'язковий, 4-8 тижнів
• Production hardening + моніторинг: +3-4 тижні
• Разом: 4-5 місяців

Зв'яжіться з нами, щоб обговорити ваш проєкт. Ми оцінимо задачу за 1-2 дні та запропонуємо оптимальну архітектуру.

Розробка крос-чейн мостів: архітектура, ризики, реалізація

Ми займаємося розробкою крос-чейн мостів та крос-чейн рішень під ключ. Знаємо, як уникнути катастроф. Кілька років тому міст Binance BNB Chain втратив $570M — атакуючий підробив Merkle proof у BSC's native bridge. Того ж року Wormhole втратив $320M (Wormhole bridge exploit): верифікація підписів guardians була обійдена через баг у Solana's secp256k1 program. Ronin Bridge — $625M. Це не випадковості. Мости — найбільш атакована інфраструктура в Web3, тому що вони агрегують ліквідність і мають складну міжланцюгову логіку верифікації. Замовте консультацію, щоб отримати захист від подібних вразливостей уже на етапі проєктування.

Чому мости ламаються: три архітектурних класи вразливостей

Проблема finality та reorg. Ethereum має probabilistic finality до Merge та economic finality після (2 епохи, ~12 хвилин). Bitcoin — ~6 блоків (~60 хвилин). Solana — ~400ms. Якщо міст мінтить wrapped tokens на цільовому ланцюгу одразу після 1-2 блоків на вихідному — reorg на 3+ блоків дозволяє атакуючому отримати токени на цільовому ланцюгу при відкаті транзакції на вихідному. Правильний захист: чекати finality confirmation, специфічний для кожного ланцюга. Для Ethereum — 64+ блоків (2 епохи). Не один блок.

Верифікація підписів. Більшість мостів використовують multisig committee або threshold signature: N з M валідаторів повинні підписати подію з вихідного ланцюга. Wormhole використовував 13 з 19 guardians. Атака була не на самі ключі — атакуючий знайшов вразливість у коді верифікації підписів на Solana, де застарілий sysvar account приймався як валідний без перевірки. On-chain верифікація підписів — складніше, ніж здається.

Lock-and-Mint vs Burn-and-Mint. У Lock-and-Mint моделі оригінальні токени заблоковані в контракті на вихідному ланцюгу, wrapped токени мінтяться на цільовому. Контракт на вихідному ланцюгу — honeypot: там весь locked TVL. Один баг в unlock логіці — і всі кошти доступні атакуючому без необхідності щось робити на цільовому ланцюгу. Native Burn-and-Mint (як у Circle CCTP для USDC) безпечніший: немає locked pool. Правильно спроектований міст з rate limiting може зекономити до $500k потенційних втрат при атаці.

Як обрати messaging layer під ваш проект?

LayerZero — протокол передачі довільних повідомлень між ланцюгами. Не міст сам по собі, а інфраструктура для побудови мостів та omnichain додатків.

Архітектура: Endpoint контракт на кожному ланцюгу, Executor (доставляє повідомлення на цільовий ланцюг), DVN (Decentralized Verifier Network — верифікує факт транзакції на вихідному ланцюгу).

Source chain:
  OApp.send() → Endpoint.send() → [emits packet event]

Destination chain:
  DVN verifies packet hash → Executor calls Endpoint.deliver() → OApp.lzReceive()

У v2 розробник обирає DVN: офіційні (LayerZero Labs, Google Cloud, Polyhedra), або кастомні. Можна налаштувати required DVN + optional DVN: повідомлення приймається тільки якщо всі required DVN підтвердили. Це дозволяє будувати мости з різним trade-off між безпекою та швидкістю.

OApp (Omnichain Application) — базовий контракт для інтеграції. Наслідуєш OApp, реалізуєш _lzSend та _lzReceive. Для токен-мостів — OFT (Omnichain Fungible Token) стандарт з коробки робить burn-on-source / mint-on-destination. LayerZero OFT інтегрується в 3 рази швидше, ніж кастомний міст.

Wormhole використовує мережу з 19 guardians (великі компанії типу Jump Crypto, Everstake тощо), кожен з яких підписує спостережувані події. Threshold — 13 з 19. VAA (Verified Action Approval) — підписане повідомлення, яке приймається на цільовому ланцюгу.

Головна відмінність від LayerZero: Wormhole має нативну підтримку не-EVM: Solana, Aptos, Sui, Algorand, Near. Для проектів, яким потрібен міст між Ethereum та Solana — Wormhole часто єдиний production-ready варіант.

Після експлойту Wormhole додав Native Token Transfers (NTT) — архітектура без locked pool, аналогічна CCTP. NTT + Hub-and-Spoke модель: надлишкова ліквідність не накопичується на одному ланцюгу.

Relay архітектура та light client верифікація

Relay-based мости (IBC в Cosmos ecosystem, Succinct's Telepathy) верифікують стан вихідного ланцюга через light client на цільовому ланцюгу. Для EVM→EVM: контракт на Ethereum зберігає та верифікує BLS-підписи блоків вихідного ланцюга.

ZK-bridges — наступний рівень. Succinct, Polyhedra zkBridge, Electron Labs генерують ZK-proof коректності консенсусу вихідного ланцюга. На цільовому ланцюгу верифікується proof, не підписи валідаторів. Усуває довіру до committee. Але верифікація ZK-proof дорога по газу — від 200k до 500k gas на Ethereum L1 залежно від системи доведень. ZK-bridge безпечніший за relay-based міст, але вимагає в 2-3 рази більше газу на верифікацію.

Що потрібно врахувати до першого рядка коду?

Обов'язкові компоненти будь-якого production мосту:

Паузер. Emergency pause функція, що викликається мультисигом або автоматично при виявленні аномалії (підозрілий обсяг, нехарактерна послідовність викликів). Більшість зламаних мостів не мали або не використовували паузер вчасно.

Rate limiting. Обмеження обсягу виводу за часовий інтервал. Якщо атакуючий дренує міст — rate limit дає час на реакцію. Реалізація: transferVolume[currentEpoch] += amount; require(transferVolume[currentEpoch] <= epochLimit).

Finality checks. Специфічні для кожного ланцюга. Не "почекати 1 блок", а використовувати finality API або чекати потрібної кількості confirmations.

Relayer моніторинг. Автономний сервіс, який слідкує за станом обох сторін мосту. Якщо повідомлення відправлено але не доставлено за N хвилин — alert. Якщо locked balance розходиться з totalSupply wrapped token — critical alert.

Що входить в розробку крос-чейн мосту

Ми реалізуємо проект під ключ і передаємо повний набір результатів. Наші замовники отримують:

Строки та вартість

Простий ERC-20 міст поверх існуючого messaging layer (LayerZero OFT або Wormhole NTT) — 4-8 тижнів включаючи тестування та аудит. Кастомний міст з власною верифікацією, multi-chain підтримкою, rate limiting, моніторингом — 12-24 тижні. ZK-bridge з кастомними proof circuits — від 6 місяців.

Аудит мосту займає більше часу, ніж аудит звичайного DeFi протоколу: потрібно тестувати cross-chain сценарії, finality edge cases, атаки через reorg. Мінімум 3-4 тижні для production-grade рішення.

Вартість розраховується індивідуально після оцінки обсягу робіт. Маємо понад 5 років досвіду в індустрії, реалізували 15+ проектів у галузі блокчейн-інфраструктури. Свяжитесь с нами для детальної консультації — оцінимо ваш проект і запропонуємо оптимальну архітектуру мосту.