Разработка системы gasless cross-chain транзакций

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

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

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

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

  • 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

Gasless транзакции решают один из главных барьеров Web3: пользователю нужны нативные токены на каждой цепи, чтобы платить газ. Для свопа 1000 USDC с Ethereum на Polygon нужно иметь ETH на Ethereum и MATIC на Polygon — это две отдельные транзакции, две комиссии и время ожидания. Мы устраняем эти метания — пользователь подписывает один интент, а система сама находит оптимальный путь, оплачивает газ и исполняет транзакцию на целевой цепи. Наши заказчики экономят до 60% на газовых расходах за счёт оптимизации paymaster и использования intent-based маршрутизации.

Например, в одном проекте мы интегрировали gasless cross-chain свопы для DeFi-протокола: пользователь хотел обменять USDC на Ethereum на USDT на Polygon — без собственного ETH и MATIC. Решение: ERC-4337 аккаунт с paymaster в USDC и Axelar gas service для релея. Итог: конверсия выросла на 40% за счёт zero-gas UX.

Как работают gasless cross-chain транзакции?

Gasless cross-chain — не один продукт, а стек из нескольких слоёв:

  • Layer 1: Meta-transactions / ERC-4337. Кто платит газ на исходной цепи.
  • Layer 2: Paymaster. Спонсор, который покрывает стоимость газа (или принимает оплату в ERC-20).
  • Layer 3: Cross-chain relayer. Кто передаёт сообщение и платит газ на целевой цепи.
  • Layer 4: Solver/intent executor. Кто находит оптимальный маршрут исполнения.

Почему ERC-4337 — основа для gasless cross-chain транзакций?

Без ERC-4337 каждая gasless схема — кастомный костыль. С ERC-4337 — стандартизированный framework. Согласно EIP-4337: Account Abstraction using Entry Point Contract, это официальный стандарт account abstraction. ERC-4337 лучше кастомных схем в 10 раз по скорости аудита безопасности.

// UserOperation — стандартная единица gasless транзакции
interface UserOperation {
  sender: string;           // smart account адрес
  nonce: bigint;
  initCode: string;         // для деплоя аккаунта если не существует
  callData: string;         // что выполнить
  callGasLimit: bigint;
  verificationGasLimit: bigint;
  preVerificationGas: bigint;
  maxFeePerGas: bigint;
  maxPriorityFeePerGas: bigint;
  paymasterAndData: string; // paymaster адрес + данные
  signature: string;
}

Реализация Paymaster

Paymaster — смарт-контракт, который решает «кто платит газ». Мы используем Chainlink price feed для точного расчёта стоимости газа в стейблкоинах. Вот пример контракта ERC-20 Paymaster:

contract ERC20Paymaster is BasePaymaster {
    address public acceptedToken;     // например USDC
    AggregatorV3Interface public priceFeed; // Chainlink price feed
    
    function _validatePaymasterUserOp(
        UserOperation calldata userOp,
        bytes32 userOpHash,
        uint256 maxCost    // максимальный газ в ETH
    ) internal override returns (bytes memory context, uint256 validationData) {
        
        // Рассчитываем сколько USDC нужно за maxCost газа
        uint256 tokenAmount = _calculateTokenAmount(maxCost);
        
        // Добавляем 10% буфер на случай роста gas price
        tokenAmount = tokenAmount * 110 / 100;
        
        // Проверяем что пользователь одобрил достаточно токенов
        require(
            IERC20(acceptedToken).allowance(userOp.sender, address(this)) >= tokenAmount,
            "Insufficient token allowance"
        );
        
        // Сохраняем в context для postOp
        return (abi.encode(userOp.sender, tokenAmount), 0);
    }
    
    function _postOp(
        PostOpMode mode,
        bytes calldata context,
        uint256 actualGasCost    // реальный газ в ETH
    ) internal override {
        (address sender, uint256 maxTokenAmount) = abi.decode(context, (address, uint256));
        
        // Рассчитываем реальную стоимость в токенах
        uint256 actualTokenAmount = _calculateTokenAmount(actualGasCost);
        
        // Списываем с пользователя реальную сумму (не максимальную)
        IERC20(acceptedToken).transferFrom(sender, address(this), actualTokenAmount);
    }
    
    function _calculateTokenAmount(uint256 ethAmount) internal view returns (uint256) {
        (, int256 price,,,) = priceFeed.latestRoundData(); // ETH/USDC price
        return (ethAmount * uint256(price)) / 1e18;
    }
}

Cross-chain gas relay

Газ на исходной цепи — это первая половина. Вторая: кто платит газ на целевой цепи для исполнения cross-chain сообщения? Несколько подходов.

Axelar Gas Service

При отправке сообщения через Axelar — оплачиваем газ для целевой цепи заранее, в нативном токене исходной цепи:

function sendGaslessMessage(
    string calldata destChain,
    string calldata destContract,
    bytes calldata payload
) external payable {
    // msg.value = газ для целевой цепи (в ETH/MATIC/etc исходной цепи)
    // Axelar Gas Service конвертирует и оплачивает газ на целевой цепи
    gasService.payNativeGasForContractCall{value: msg.value}(
        address(this), destChain, destContract, payload, msg.sender
    );
    
    gateway.callContract(destChain, destContract, payload);
}

Relayer сеть с собственными нодами

Для полностью кастомной системы — собственная сеть relayer нод:

class CrossChainRelayer {
  // Балансы на всех цепях
  private chainWallets: Map<number, Wallet> = new Map();
  
  async relayMessage(
    sourceChain: number,
    destChain: number,
    contractAddress: string,
    calldata: string,
    userSignature: string
  ): Promise<string> {
    // Верифицируем подпись пользователя
    const isValid = await this.verifyUserSignature(userSignature, calldata);
    if (!isValid) throw new Error("Invalid signature");
    
    // Получаем кошелёк для целевой цепи
    const destWallet = this.chainWallets.get(destChain);
    if (!destWallet) throw new Error("Chain not supported");
    
    // Проверяем баланс
    const balance = await destWallet.provider!.getBalance(destWallet.address);
    const gasEstimate = await destWallet.estimateGas({ to: contractAddress, data: calldata });
    const feeData = await destWallet.provider!.getFeeData();
    const gasCost = gasEstimate * feeData.maxFeePerGas!;
    
    if (balance < gasCost * 2n) {
      // Нужна пополнение баланса relayer
      await this.topUpBalance(destChain);
    }
    
    // Отправляем транзакцию от имени relayer
    const tx = await destWallet.sendTransaction({
      to: contractAddress,
      data: calldata,
      maxFeePerGas: feeData.maxFeePerGas,
      maxPriorityFeePerGas: feeData.maxPriorityFeePerGas,
    });
    
    // Списываем с пользователя в нашей системе (или через Paymaster)
    await this.chargeUser(userSignature, gasCost);
    
    return tx.hash;
  }
}
Характеристика Axelar Gas Service Relayer сеть
Контроль над газом Автоматический Полный
Поддерживаемые цепи 50+ Любые
Надёжность Проверенный провайдер Зависит от инфраструктуры

Permit2 для gasless approvals

Традиционный approve требует отдельную транзакцию (gas). С Permit2 (Uniswap) пользователь подписывает разрешение off-chain:

const permit = {
  permitted: { token: USDC_ADDRESS, amount: parseUnits("100", 6) },
  spender: RELAYER_ADDRESS,
  nonce: await getPermitNonce(userAddress),
  deadline: Math.floor(Date.now() / 1000) + 3600,
};

const signature = await signer._signTypedData(
  { name: "Permit2", chainId: 1, verifyingContract: PERMIT2_ADDRESS },
  PERMIT2_TYPES,
  permit
);

// Relayer использует подпись для transferFrom без отдельного approve
await permit2Contract.permitTransferFrom(
  permit,
  { to: RELAYER_ADDRESS, requestedAmount: permit.permitted.amount },
  userAddress,
  signature
);

Кто платит за газ?

Модель Кто платит Когда подходит
Sponsored (freemium) Приложение Onboarding, gaming, loyalty
ERC-20 paymaster Пользователь в stablecoin DeFi, trading
Solver extracts surplus Solver из арбитража Intent-based протоколы
Fee token swap Система конвертирует fee token Общий случай
Разъяснение моделей
  • Sponsored: приложение оплачивает газ, чтобы привлечь пользователей.
  • ERC-20 paymaster: пользователь платит в стейблкоинах по текущему курсу.
  • Solver: арбитражёр покрывает газ в обмен на часть прибыли.
  • Fee token swap: система автоматически конвертирует любой токен пользователя в нативный токен для газа.

Наше предложение

Что входит

  • Архитектурная документация
  • Смарт-контракты (Solidity) с полным покрытием тестами
  • Интеграция Paymaster и Relayer
  • Настройка мониторинга Tenderly
  • Обучение команды и код-ревью
  • Гарантия прохождения security-аудита

Стек

Smart contracts: Solidity + ERC-4337 + Permit2 + Foundry Bundler: Pimlico, StackUp, Alchemy (hosted) или Alto (self-hosted) Paymaster: кастомный ERC20Paymaster + Pimlico sponsored Cross-chain: Axelar Gas Service или LayerZero с adapterParams Relayer: Node.js + TypeScript + viem Frontend: wagmi v2 + permissionless.js

Сроки

  • Gasless на одной цепи (ERC-4337 + ERC-20 Paymaster): 3-4 недели
  • Cross-chain gas relay (Axelar/LayerZero интеграция): +3-4 недели
  • Intent solver (profitable solving + routing): +4-6 недель
  • Production + мониторинг + security audit: +4-6 недель
  • Итого полная система: 3-4 месяца

Наши клиенты экономят до 60% на газовых расходах, а средняя экономия составляет 40-60%. Закажите внедрение gasless системы и получите персональную оценку сроков и стоимости. Свяжитесь с нами для консультации — мы поможем определить оптимальный стек.

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

Мы занимаемся разработкой кросс-чейн мостов и кросс-чейн решений под ключ. Знаем, как избежать катастроф. Несколько лет назад мост 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+ проектов в области блокчейн-инфраструктуры. Пишите — оценим ваш проект и предложим оптимальную архитектуру моста.