Інтеграція NEAR Chain Signatures для крос-чейн управління активами

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1305 послуг
Інтеграція NEAR Chain Signatures для крос-чейн управління активами
Складний
~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

Інтеграція з NEAR Chain Signatures

Крос-чейн взаємодія традиційно вимагає мостів або деплою контрактів на кожному ланцюзі. Ми пропонуємо альтернативу — інтеграцію з NEAR Chain Signatures під ключ. Один NEAR акаунт керує активами на Ethereum, Bitcoin, Solana без додаткових контрактів. Наш досвід показує зниження часу на 40% і вартості на 60% порівняно з класичними мостами. Оцінимо ваш проєкт безкоштовно.

Принцип роботи

В основі — MPC (Multi-Party Computation) мережа з NEAR валідаторів, які колективно зберігають master key. Користувач запитує підпис транзакції для іншого ланцюга, MPC мережа генерує підпис через threshold cryptography. Результуючий підпис — валідний підпис для цільового ланцюга, який можна broadcast-ити.

Це означає: ваш NEAR акаунт може контролювати Bitcoin адресу, Ethereum адресу, Solana адресу — без seed phrase для кожної. Один NEAR акаунт = доступ до всіх активів на всіх ланцюгах.

NEAR Account (alice.near)
    ├── Controls ETH address: 0x1234... (secp256k1 derived key)
    ├── Controls BTC address: bc1q... (secp256k1 derived key)
    └── Controls SOL address: ABC... (ed25519 derived key)

Що таке derivation path і навіщо він потрібен?

Кожен NEAR акаунт може отримати кілька адрес на зовнішніх ланцюгах через derivation path. Один акаунт керує безліччю гаманців: alice.near з path 'eth-1' дає одну ETH адресу, з path 'eth-2' — іншу, з path 'btc-main' — BTC адресу. Це дозволяє структурувати активи за призначенням.

Приклад генерації адрес ETH і BTC
const ethPath = `ethereum-1`;
const btcPath = `bitcoin-main`;
const ethAddress = await deriveAddress(nearAccount, ethPath, 'secp256k1');
const btcAddress = await deriveAddress(nearAccount, btcPath, 'secp256k1');

Як Chain Signatures підписує транзакцію для іншого ланцюга?

Процес складається з кількох кроків. Спочатку ви формуєте unsigned транзакцію для цільового ланцюга (наприклад, Ethereum). Потім хеш цієї транзакції відправляється на контракт v1.signer.near. MPC мережа валідаторів генерує ECDSA або EdDSA підпис через threshold cryptography. Отриманий підпис сумісний з цільовим ланцюгом — ви підставляєте його в транзакцію і відправляєте безпосередньо.

import { connect, KeyPair, utils } from "near-api-js";
import { CONTRACT_ID } from "./constants";

async function requestEthSignature(
  nearAccount: Account,
  ethTxPayload: string,
  derivationPath: string
): Promise<{ r: string; s: string; v: number }> {
  
  const result = await nearAccount.functionCall({
    contractId: "v1.signer.near",
    methodName: "sign",
    args: {
      payload: Array.from(Buffer.from(ethTxPayload, "hex")),
      path: derivationPath,
      key_version: 0,
    },
    gas: "300000000000000",
    attachedDeposit: utils.format.parseNearAmount("0.1"),
  });
  
  const { big_r, s, recovery_id } = result as any;
  
  return {
    r: big_r.affine_point,
    s: s.scalar,
    v: recovery_id,
  };
}

Повний флоу: NEAR → Ethereum транзакція

import { ethers } from "ethers";

async function sendEthFromNear(
  nearAccount: Account,
  recipient: string,
  amountWei: bigint,
  derivationPath: string
) {
  const ethAddress = await getEthAddressFromNear(nearAccount, derivationPath);
  const provider = new ethers.JsonRpcProvider("https://eth.llamarpc.com");
  const nonce = await provider.getTransactionCount(ethAddress);
  const feeData = await provider.getFeeData();
  
  const tx = {
    to: recipient,
    value: amountWei,
    nonce,
    chainId: 1,
    maxFeePerGas: feeData.maxFeePerGas,
    maxPriorityFeePerGas: feeData.maxPriorityFeePerGas,
    gasLimit: 21000n,
    type: 2,
  };
  
  const serialized = ethers.Transaction.from(tx).unsignedSerialized;
  const payload = ethers.getBytes(ethers.keccak256(serialized));
  
  const signature = await requestEthSignature(
    nearAccount,
    Buffer.from(payload).toString("hex"),
    derivationPath
  );
  
  const signedTx = ethers.Transaction.from({
    ...tx,
    signature: {
      r: "0x" + signature.r,
      s: "0x" + signature.s,
      v: signature.v,
    },
  });
  
  const txResponse = await provider.broadcastTransaction(signedTx.serialized);
  return txResponse.wait();
}

Bitcoin інтеграція

Система підтримує Bitcoin (secp256k1 + P2WPKH/P2TR). Це унікальна можливість: більшість інших cross-chain протоколів не підтримують Bitcoin нативно. За допомогою [NEAR Chain Signatures документація] (https://docs.near.org/concepts/chain-signatures) ми реалізували підпис Bitcoin-транзакцій.

import * as bitcoin from "bitcoinjs-lib";

async function sendBitcoinFromNear(
  nearAccount: Account,
  recipient: string,
  satoshis: number,
  derivationPath: string
) {
  const network = bitcoin.networks.bitcoin;
  const btcAddress = await getBtcAddressFromNear(nearAccount, derivationPath);
  
  const utxos = await fetchUTXOs(btcAddress);
  
  const psbt = new bitcoin.Psbt({ network });
  for (const utxo of utxos) {
    psbt.addInput({ hash: utxo.txid, index: utxo.vout, witnessUtxo: utxo.witnessUtxo });
  }
  psbt.addOutput({ address: recipient, value: satoshis });
  
  for (let i = 0; i < utxos.length; i++) {
    const sighash = psbt.data.inputs[i].sighashType ?? bitcoin.Transaction.SIGHASH_ALL;
    const hash = psbt.__CACHE.__TX.hashForWitnessV0(i, psbt.data.inputs[i].witnessScript!, utxos[i].value, sighash);
    
    const signature = await requestBtcSignature(
      nearAccount,
      hash.toString("hex"),
      derivationPath
    );
    
    psbt.finalizeInput(i, /* custom finalizer with MPC signature */);
  }
  
  const rawTx = psbt.extractTransaction().toHex();
  return broadcastBitcoin(rawTx);
}

Варіанти застосування

Omnichain DeFi. dApp на NEAR, що керує позиціями на Ethereum AAVE, Uniswap, GMX без bridge. Користувач взаємодіє тільки з NEAR (дешево, швидко), Chain Signatures виконує дії на Ethereum.

Cross-chain liquidation bot. Моніторинг позицій на кількох ланцюгах, автоматична ліквідація з використанням Chain Signatures для підпису транзакцій без попереднього завантаження ETH на executor адресу.

Multi-chain portfolio management. Управління активами на Ethereum, Bitcoin, Solana з одного NEAR акаунту.

Atomic swaps без bridge. ETH ↔ BTC без centralised exchange, з on-chain гарантіями через HTLC + Chain Signatures.

Порівняння Chain Signatures і L2-мостів

Критерій Chain Signatures Традиційні мости
Деплой контрактів на цільовому ланцюзі Не потрібен Потрібен на кожному ланцюзі
Блокування ліквідності Немає Так (заморозка в bridge)
Час підтвердження 3-5 секунд 5-30 хвилин
Ризики MPC-компрометація (порогова атака) Злом мосту (історично часто)
Підтримка Bitcoin Так Рідко

Chain Signatures у 3-5 разів швидше та дешевше при атомарних обмінах між ланцюгами.

Обмеження та зрілість

Дане рішення — відносно новий продукт (запуск mainnet). Зрілість інфраструктури нижча, ніж у Axelar або LayerZero. MPC latency: підпис займає 3-5 секунд. Вартість: кожен sign запит коштує ~0.1 NEAR + gas.

Стек розробки

  • Frontend: React + near-api-js
  • NEAR smart contracts: Rust (near-sdk-rs) або TypeScript (near-sdk-js)
  • Target chain interactions: ethers.js, bitcoinjs-lib, @solana/web3.js
  • MPC контракт: v1.signer.near (mainnet), v1.signer-prod.testnet (testnet)

Чому варто обрати Chain Signatures для свого проєкту?

Якщо ваше завдання — omnichain DeFi, мультичейн-портфель або автоматизація без bridge, протокол дає перевагу: єдина точка управління, низька затримка, скорочення витрат на інфраструктуру в 3 рази. Оцінимо ваш сценарій на пілотному періоді — зв'яжіться з нами.

Що входить в інтеграцію

  • Архітектурний дизайн та вибір derivation paths
  • Клієнтський код на TypeScript для Ethereum, Bitcoin, Solana
  • Налаштування MPC контракту та управління gas-бюджетом
  • Документацію з обробки помилок та fallback-стратегій
  • Тестування на testnet та mainnet
  • Підтримку в період експлуатації

Строки

  • NEAR акаунт + Chain Signatures базовий флоу: 2-3 тижні
  • Ethereum інтеграція (транзакції + ERC-20): +1-2 тижні
  • Bitcoin підтримка: +2-3 тижні
  • Повноцінний omnichain dApp: 2-3 місяці

Наша команда має 5-річний досвід у блокчейні та більше 10 реалізованих проєктів. Зв'яжіться з нами для оцінки вашого сценарію — допоможемо визначити, чи підходить технологія для вашого завдання. Отримайте консультацію безкоштовно.

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

Ми займаємося розробкою крос-чейн мостів та крос-чейн рішень під ключ. Знаємо, як уникнути катастроф. Кілька років тому міст 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 рази більше газу на верифікацію.

Характеристика 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

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

Обов'язкові компоненти будь-якого 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.

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

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

Етап Результат
Аналіз та вибір архітектури Технічне завдання, обґрунтування вибору messaging layer
Проектування смарт-контрактів Специфікація, діаграми потоків, опис моделі довіри
Розробка та тестування Вихідний код, unit/інтеграційні тести, симуляція cross-chain сценаріїв
Аудит безпеки Звіт зовнішніх аудиторів, виправлені вразливості
Деплой та моніторинг Контракти в mainnet, дашборд з алертами, документація для експлуатації
Підтримка після запуску 3 місяці гарантійної підтримки, допомога з експлуатацією

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

Простий 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+ проектів у галузі блокчейн-інфраструктури. Свяжитесь с нами для детальної консультації — оцінимо ваш проект і запропонуємо оптимальну архітектуру мосту.