Интеграция Axelar: безопасные кросс-чейн вызовы и передача токенов

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Интеграция Axelar: безопасные кросс-чейн вызовы и передача токенов
Средний
~3-5 дней
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1374
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1256
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    965
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1208
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    667
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    954

При разработке кросс-чейн решений безопасность мостов — главный риск. Взломы Cross-chain bridge и Ronin показали уязвимость multisig-схем с 5-of-9 валидаторами: компрометация группы приводит к потере средств. Мы используем Axelar — децентрализованную сеть с порогом атаки 2/3 из ~75 валидаторов по стейку. Это в 10 раз безопаснее, чем Multichain. Наш опыт — 5+ лет в Web3 и 20+ успешных интеграций — гарантирует надёжность реализации.

Почему Axelar безопаснее других мостов?

Axelar использует proof-of-stake с threshold signatures (BLS). Валидаторы имеют долю в сети, и для подписи транзакции нужна кооперация >2/3 стейка. Это в 10 раз сложнее взломать, чем мост с 5-of-9 multisig. Кроме того, Axelar регулярно проходит аудит безопасности ведущими фирмами, такими как Trail of Bits. В документации Axelar указано: Gas Service автоматически оплачивает газ на целевой цепи, избавляя пользователя от ручного управления.

Решаемые проблемы

Кросс-чейн взаимодействие сталкивается с тремя основными вызовами:

  • Безопасность: уязвимые мосты с малым числом валидаторов.
  • Газовые затраты: двойная оплата газа на обеих цепях, часто с переплатой.
  • Сложность интеграции: необходимость управлять ключами, релеями и статусами.

Axelar решает все три: threshold signatures повышают безопасность, Gas Service автоматизирует оплату, а GMP упрощает вызовы. Типичная ошибка — неверный расчёт газа для целевой цепочки, что приводит к недоставке сообщения. Использование AxelarGMPRecoveryAPI позволяет избежать этого.

Что умеет Axelar

GMP (General Message Passing) — передача произвольных сообщений между цепями. Не только токены: можно вызвать функцию смарт-контракта в другой цепи с произвольными данными.

Canonical token bridging — стандартизированный перевод токенов. USDC через Axelar — это Circle's native USDC (через Circle CCTP) или Axelar Wrapped USDC (axlUSDC), в зависимости от настройки.

Squid — DEX агрегатор поверх Axelar, позволяет делать cross-chain swaps в одну транзакцию (swap на исходной цепи + bridge + swap на целевой).

GMP интеграция

Контракт на исходной цепи

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

import { AxelarExecutable } from "@axelar-network/axelar-gmp-sdk-solidity/contracts/executable/AxelarExecutable.sol";
import { IAxelarGateway } from "@axelar-network/axelar-gmp-sdk-solidity/contracts/interfaces/IAxelarGateway.sol";
import { IAxelarGasService } from "@axelar-network/axelar-gmp-sdk-solidity/contracts/interfaces/IAxelarGasService.sol";

contract SourceContract {
    IAxelarGateway public gateway;
    IAxelarGasService public gasService;
    
    constructor(address _gateway, address _gasService) {
        gateway = IAxelarGateway(_gateway);
        gasService = IAxelarGasService(_gasService);
    }
    
    function sendCrossChainMessage(
        string calldata destinationChain,      // "Polygon", "avalanche", "binance"
        string calldata destinationAddress,    // адрес контракта-получателя
        bytes calldata payload
    ) external payable {
        // Оплачиваем газ для исполнения на целевой цепи
        gasService.payNativeGasForContractCall{value: msg.value}(
            address(this),
            destinationChain,
            destinationAddress,
            payload,
            msg.sender
        );
        
        // Отправляем сообщение
        gateway.callContract(destinationChain, destinationAddress, payload);
    }
}

Контракт на целевой цепи

contract DestinationContract is AxelarExecutable {
    event MessageReceived(string sourceChain, string sourceAddress, bytes payload);
    
    constructor(address gateway) AxelarExecutable(gateway) {}
    
    // Вызывается Axelar когда сообщение доставлено
    function _execute(
        string calldata sourceChain,
        string calldata sourceAddress,
        bytes calldata payload
    ) internal override {
        // Декодируем payload
        (address recipient, uint256 amount) = abi.decode(payload, (address, uint256));
        
        // Выполняем бизнес-логику
        _processMessage(sourceChain, sourceAddress, recipient, amount);
        
        emit MessageReceived(sourceChain, sourceAddress, payload);
    }
}

Как интегрировать GMP за 2-4 недели?

Процесс включает следующие шаги:

  1. Проектирование: выбор цепей, контрактов, дизайн взаимодействия.
  2. Разработка смарт-контрактов на Solidity с использованием Foundry/Hardhat.
  3. Деплой на testnet и настройка Gas Service.
  4. Тестирование кросс-чейн сценариев на testnet.
  5. Аудит безопасности (опционально).
  6. Деплой на mainnet и мониторинг.
Этап Длительность Описание
Аналитика 1-2 дня Определение цепей, контрактов, маршрутов
Разработка 5-10 дней Написание контрактов, настройка SDK
Тестирование 3-5 дней Testnet, gas estimation
Деплой + аудит 2-4 дня Mainnet, аудит кода

Как рассчитать газ для кросс-чейн вызова?

Ключевая деталь Axelar GMP — Gas Service. Пользователь оплачивает газ для обеих цепей в одной транзакции (на исходной цепи). Axelar Gas Service конвертирует нативный токен и оплачивает реле на целевой цепи. Расчёт нужного газа через AxelarGMPRecoveryAPI:

import { AxelarQueryAPI, Environment, GasToken } from "@axelar-network/axelarjs-sdk";

const api = new AxelarQueryAPI({ environment: Environment.MAINNET });

const gasEstimate = await api.estimateGasFee(
  "Ethereum",           // source chain
  "Polygon",            // destination chain
  GasToken.ETH,
  300_000,              // gas limit на destination
  1.1                   // 10% buffer
);

// gasEstimate — сумма в wei для передачи в payNativeGasForContractCall

Средняя стоимость газа для одного вызова составляет около $10, но экономия на автоматизации может достигать $5000 в месяц для активных проектов. Свяжитесь с нами для оценки вашего проекта.

Token Transfer с GMP

Для transfer токена + вызов функции на целевой цепи — callContractWithToken:

function sendTokenAndCall(
    string calldata destinationChain,
    string calldata destinationAddress,
    bytes calldata payload,
    string calldata symbol,  // "USDC", "WETH"
    uint256 amount
) external payable {
    IERC20(gateway.tokenAddresses(symbol)).transferFrom(msg.sender, address(this), amount);
    IERC20(gateway.tokenAddresses(symbol)).approve(address(gateway), amount);
    
    gasService.payNativeGasForContractCallWithToken{value: msg.value}(
        address(this), destinationChain, destinationAddress, payload, symbol, amount, msg.sender
    );
    
    gateway.callContractWithToken(destinationChain, destinationAddress, payload, symbol, amount);
}

Сравнение Axelar с другими мостами

Характеристика Axelar Multichain Ronin
Механизм валидации PoS + threshold signatures Multisig 5-of-9 Multisig 5-of-9
Количество валидаторов ~75 9 9
Порог атаки >2/3 стейка 5 ключей 5 ключей
Кросс-чейн вызовы GMP (любые данные) Только токены Только токены
Поддержка Cosmos Да (IBC) Нет Нет

Squid интеграция для cross-chain swaps

import { Squid } from "@0xsquid/sdk";

const squid = new Squid({ baseUrl: "https://apiplus.squidrouter.com" });
await squid.init();

const { route } = await squid.getRoute({
  fromAddress: userAddress,
  fromChain: "1",                // Ethereum
  fromToken: "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE", // ETH
  fromAmount: "1000000000000000000", // 1 ETH
  toChain: "137",                // Polygon
  toToken: "0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174", // USDC
  toAddress: recipientAddress,
  slippage: 1.0,                 // 1%
  enableBoost: true,
});

// Выполнение свапа
const tx = await signer.sendTransaction(route.transactionRequest);

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

  • Аналитическая документация: схема взаимодействия цепей, выбор контрактов.
  • Разработка и деплой смарт-контрактов на Solidity (с использованием Foundry/Hardhat).
  • Настройка Gas Service и расчёт газа.
  • Интеграция Squid для кросс-чейн свапов (опционально).
  • Тестирование на testnet и mainnet.
  • Документация по интеграции и поддержка после запуска.

Оценим ваш проект под ключ. Оставьте заявку на консультацию — мы поможем реализовать кросс-чейн функционал безопасно и в срок.

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

Мы занимаемся разработкой кросс-чейн мостов и кросс-чейн решений под ключ. Знаем, как избежать катастроф. Несколько лет назад мост Binance BNB Chain потерял $570M — атакующий подделал Merkle proof в BSC's native bridge. В том же году Wormhole потерял $320M: верификация подписей 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.

Как выбрать 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.

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 раза больше газа на верификацию.

Характеристика LayerZero Wormhole IBC (Cosmos) ZK-bridge
EVM поддержка Все EVM + Solana, Aptos Все EVM + Solana, Aptos, Sui Cosmos chains Растёт
Модель доверия DVN (выбирается) 13/19 guardians Light client ZK proof
Latency 1-5 мин 1-5 мин ~30 сек 5-30 мин
Gas на верификацию ~100-150k ~150-200k ~200-300k 200-500k

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

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

Этап Результат
Анализ и выбор архитектуры Техническое задание, обоснование выбора messaging layer
Проектирование смарт-контрактов Спецификация, диаграммы потоков, описание модели доверия
Разработка и тестирование Исходный код, unit/интеграционные тесты, симуляция cross-chain сценариев
Аудит безопасности Отчёт внешних аудиторов, исправленные уязвимости
Деплой и мониторинг Контракты в mainnet, дашборд с алертами, документация для эксплуатации
Поддержка после запуска 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 решения.

Стоимость рассчитывается индивидуально после оценки объёма работ. Работаем с 2018 года, реализовали 15+ проектов в области блокчейн-инфраструктуры. Пишите — оценим ваш проект и предложим оптимальную архитектуру моста.