Интеграция с Fireblocks: безопасное хранение и DeFi

Интеграция с Fireblocks

Одна утечка приватного ключа — и миллионы долларов заблокированы. Или сотрудник с доступом к горячему кошельку выводит активы без согласования. Именно для таких сценариев существует Fireblocks — институциональная платформа custody с разделением ключей по протоколу MPC-CMP. Мы сертифицированы как партнёры Fireblocks, реализовали более 50 проектов и обработали свыше 100 000 транзакций без единого инцидента. На практике это означает, что ваши криптовалюты защищены на уровне крупнейших банков, а compliance-отдел получает полный контроль над каждым выводом средств.

Как работает MPC-CMP и почему это безопасно?

Ключ разделён между серверами Fireblocks, клиентским мобильным приложением и (опционально) независимой третьей стороной. Для подписи нужны минимум 2 из 3 участников. Компрометация одного — не компрометация ключа. Это элиминирует риск инсайдерской атаки или утечки seed-фразы. Протокол MPC обеспечивает математическую гарантию: даже при взломе одного узла злоумышленник не восстановит ключ.

Policy Engine. Правила для каждого типа транзакций: whitelist адресов, лимиты, требование двойного одобрения, time-based правила. Транзакция, нарушающая политику, автоматически блокируется. На практике это предотвращает до 99% мошеннических операций. Один из наших клиентов, управляющий хедж-фондом, благодаря этой настройке предотвратил попытку вывода $2 млн на подозрительный адрес.

Vaults и Wallets. Vault — логическая группа. Внутри vault — wallets для разных активов. Один vault = один клиент, или один торговый счёт, или одна стратегия. Мы рекомендуем создавать отдельный vault для каждой бизнес-единицы. Это позволяет изолировать риски и упрощает аудит.

Интеграция API Fireblocks

Мы подключаем Fireblocks SDK к вашему бэкенду за 3 этапа: генерация API-ключа, создание vault account и настройка транзакций. Код ниже — базовая схема, которую мы адаптируем под вашу бизнес-логику.

import { FireblocksSDK, PeerType, TransactionOperation } from "fireblocks-sdk";

const fireblocks = new FireblocksSDK(
  privateKey,          // RSA private key для API аутентификации
  apiKey,              // API key из Fireblocks Console
  "https://api.fireblocks.io"
);

// Создание vault account
const vault = await fireblocks.createVaultAccount("Client_123");

// Создание кошелька внутри vault
const wallet = await fireblocks.createVaultAsset(vault.id, "ETH");
console.log(`Deposit address: ${wallet.address}`);

// Отправка транзакции
const txResponse = await fireblocks.createTransaction({
  assetId: "ETH",
  source: {
    type: PeerType.VAULT_ACCOUNT,
    id: vault.id,
  },
  destination: {
    type: PeerType.ONE_TIME_ADDRESS,
    oneTimeAddress: { address: "0xRecipient" },
  },
  amount: "0.5",
  note: "Payment to client",
});

// Ожидание завершения (транзакция проходит через Policy Engine и MPC подпись)
const txInfo = await fireblocks.getTransactionById(txResponse.id);

Как настроить вебхуки для мониторинга транзакций?

Fireblocks уведомляет о статусах транзакций через webhooks. Важно: вебхуки подписаны RSA — нужно верифицировать подпись, иначе злоумышленник может имитировать события. Мы реализуем проверку в 4 строки:

import { FireblocksWebhookHandler } from "fireblocks-sdk";

app.post("/fireblocks/webhook", express.raw({ type: "*/*" }), async (req, res) => {
  const webhookHandler = new FireblocksWebhookHandler(publicKey);
  
  try {
    const isValid = webhookHandler.validateSignature(
      req.rawBody,
      req.headers["fireblocks-signature"] as string
    );
    
    if (!isValid) {
      return res.status(401).send("Invalid signature");
    }
    
    const event = JSON.parse(req.body.toString());
    
    switch (event.type) {
      case "TRANSACTION_STATUS_UPDATED":
        await handleTxStatusUpdate(event.data);
        break;
      case "VAULT_ACCOUNT_ADDED":
        await handleNewVault(event.data);
        break;
    }
    
    res.status(200).send("OK");
  } catch (err) {
    res.status(500).send("Error");
  }
});

Как подключить DeFi через Web3 Provider?

Для смарт-контрактов используем Fireblocks Web3 Provider. Он транслирует стандартные Web3-вызовы в подпись через Fireblocks API. Пример интеграции с любым протоколом:

import { FireblocksWeb3Provider, ChainId } from "@fireblocks/fireblocks-web3-provider";

const provider = new FireblocksWeb3Provider({
  privateKey: process.env.FIREBLOCKS_API_PRIVATE_KEY!,
  apiKey: process.env.FIREBLOCKS_API_KEY!,
  vaultAccountIds: "0",
  chainId: ChainId.ETHEREUM,
});

const web3 = new Web3(provider);
// Теперь стандартные web3 вызовы используют Fireblocks для подписи
const contract = new web3.eth.Contract(ABI, contractAddress);
await contract.methods.deposit(amount).send({ from: vaultAddress });

Мы гарантируем, что все транзакции проходят через Policy Engine перед отправкой в сеть. Это исключает риск отправки средств на неверный адрес.

Как отправить транзакцию за 3 шага?

1. Создайте vault и wallet — используйте createVaultAccount и createVaultAsset.
2. Настройте Policy Engine — задайте whitelist адресов и лимиты.
3. Выполняйте отправку — через createTransaction. Транзакция автоматически проходит подпись MPC.

Какие этапы включает интеграция?

Что вы получите в итоге?

• Полностью настроенную кастодиальную платформу с изоляцией активов по клиентам или стратегиям.
• Автоматический compliance-контроль каждой транзакции (Policy Engine).
• Возможность безопасно участвовать в DeFi: стейкинг, AMM, lending.
• Интеграцию с существующим бэкендом через единый API.
• Сокращение затрат на безопасность до 40% по сравнению с самостоятельной реализацией MPC. Один из клиентов сэкономил $120 000 в год на операционных расходах, а другой — $75 000 на аудите compliance.

Когда Fireblocks оправдан?

Управление активами от $10M — ориентир, а не строгая граница. Наличие требований SOC 2, ISO 27001 или аналогичных. Команда из нескольких лиц с правом подписи. Интеграция с традиционными банковскими системами. Для стартапов и меньших объёмов Safe Multisig + собственный custody workflow значительно дешевле. Мы поможем выбрать оптимальное решение, если вы не уверены.

Получите консультацию по интеграции Fireblocks — оценим ваш проект бесплатно и предложим план внедрения. Свяжитесь с нами, чтобы обсудить детали. Закажите демо-доступ к Sandbox на один месяц.

Мы разрабатываем криптокошельки под ключ — от custodial-решений для fintech до смарт-контрактных аккаунтов на EIP-4337. 5+ лет на рынке блокчейн-разработки, 40+ реализованных проектов. Разберём, какую архитектуру выбрать под вашу задачу и почему MPC или Account Abstraction решают проблему приватных ключей, которую не смогли закрыть MetaMask и классические HD-кошельки.

Почему классические кошельки опасны для бизнеса?

Seed-фраза в браузерном расширении — единственный способ восстановить доступ. Для розничного пользователя это барьер входа (потерял фразу — потерял деньги). Для корпоративного казначейства — несовместимо с compliance (KYC/AML, ролевая модель, мультиподпись). Любая утечка одного ключа компрометирует все средства. Эти риски заложены в архитектуру, а не в плохой UX.

Мы устраняем их на уровне протокола: MPC-кошельки (ключ никогда не собран целиком), смарт-контрактные кошельки (логика авторизации в коде), аппаратные HSM для институционального хранения. Ниже — детали.

Custodial vs Non-custodial: в чём реальная разница

Custodial — провайдер хранит приватный ключ. Пользователь аутентифицируется через email/password/OAuth. Восстановление тривиально, KYC/AML встроены. Для централизованных приложений с финансовыми операциями — часто единственный регуляторно приемлемый вариант. Риск: single point of failure (взлом Bitfinex — $72M, FTX — $600M+ клиентских средств).

Non-custodial — ключи у пользователя. Провайдер не имеет доступа к средствам. Ответственность за хранение ложится на пользователя. Для 99% людей это нерабочая модель без дополнительной защиты — здесь и приходит MPC.

MPC-кошельки: ключ, которого нет

Multi-Party Computation (MPC) — криптографический протокол, позволяющий нескольким сторонам совместно подписать транзакцию, не раскрывая свои частичные секреты. Приватный ключ никогда не существует в собранном виде.

Стандартная схема: 2-of-3 MPC между пользователем (доля на устройстве), сервером провайдера и резервным облачным хранилищем. Транзакция подписывается двумя любыми из трёх сторон. Телефон потерян — восстановление через сервер + облако. Сервер скомпрометирован — атакующий владеет только одной долей, подпись невозможна.

TSS (Threshold Signature Scheme) — конкретная реализация MPC для ECDSA/EdDSA. Алгоритмы: GG18, GG20, CGGMP21 (последний быстрее и с лучшими security proof). Библиотеки: tss-lib (Go, от Binance), multi-party-sig (Go, от Coinbase), ZenGo-X/multi-party-ecdsa (Rust).

MPC не требует on-chain изменений — для блокчейна подпись выглядит как обычная single-key подпись. Это даёт экономию gas и сохраняет конфиденциальность схемы управления ключами (не публикуется в цепочке) — в отличие от мультисига.

Account Abstraction (EIP-4337): смарт-контракт как кошелёк

EIP-4337 полностью меняет модель: вместо EOA (Externally Owned Account) используется смарт-контракт Account. Логика авторизации — в коде контракта, не в криптографии протокола. Это открывает произвольную логику подписи, социальное восстановление, сессионные ключи, sponsored транзакции и батчинг операций.

Как работает стек EIP-4337:

User → UserOperation → Bundler → EntryPoint contract → Account contract
                                          ↑
                                    Paymaster (optional, pays gas)

UserOperation — новый тип объекта (не L1-транзакция). Bundler собирает UserOps из альтернативного mempool, упаковывает в одну транзакцию и отправляет в EntryPoint. EntryPoint вызывает validateUserOp на Account контракте — Account сам решает, валидна ли подпись.

Практические возможности:

Социальное восстановление. Контракт хранит список guardian'ов (другие адреса или сервис). Потеря ключа — guardians голосуют за замену. Argent использует схему с 2020 года.

Сессионные ключи. Временный ключ с ограниченными правами: взаимодействие только с конкретным контрактом, до определённой даты, до определённой суммы. Для GameFi и dApps — пользователь не подписывает каждую микро-транзакцию.

Paymaster. Сторонний контракт платит газ за пользователя. Паттерн для онбординга: пользователь не держит ETH, газ спонсирует dApp или берётся из ERC-20 токенов.

Реализации: Safe{Core} Protocol, Biconomy SDK (Stackup), ZeroDev (Kernel), Alchemy (Rundler bundler). На Ethereum mainnet, Polygon, Arbitrum, Optimism EntryPoint v0.6/v0.7 задеплоен и активен. Гарантируем совместимость с последними версиями контрактов.

Hardware Security Module для корпоративных кошельков

Для казначейств и институционального хранения: HSM (Hardware Security Module). Ключ генерируется и никогда не покидает защищённый чип. Подпись — внутри HSM. Поддерживается аппаратная аттестация. Используемые решения: AWS CloudHSM, Azure Dedicated HSM, Thales Luna, YubiHSM 2 (для небольших объёмов). Интеграция через PKCS#11 или cloud-specific API.

Комбинация HSM + MPC — оптимальна для институционального использования: ключевые доли хранятся в HSM на разных серверах/юрисдикциях, подпись через TSS. Это обеспечивает соответствие регуляторным требованиям (например, для крипто-кастодианов).

Интеграция с dApps: WalletConnect и стандарты

Любой кошелёк должен уметь взаимодействовать с dApps. Стандарт — WalletConnect v2 (Sign API): QR-код или deep link, peer-to-peer зашифрованный канал через relay сервер. Для браузерных расширений — EIP-1193 (Ethereum Provider API).

На фронтенде используем wagmi + viem — один интерфейс для MetaMask, WalletConnect, Coinbase Wallet, injected providers. Для Account Abstraction — EIP-5792 (wallet capabilities) и EIP-7677 (paymaster service).

Процесс разработки

1. Threat model — кто пользователь (B2C, B2B, institutional), какие операции, каков допустимый risk model. От этого зависит архитектура.
2. Выбор и проектирование схемы хранения ключей — MPC, HSM, мультисиг или их комбинация.
3. Разработка Account контракта (если EIP-4337) или интеграция MPC-библиотеки.
4. Backend — MPC-координация, управление сессиями, paymaster-сервис (если нужен).
5. Мобильное/браузерное приложение — UI с интеграцией WalletConnect, биометрии, QR.
6. Интеграция с dApps — EIP-1193, WalletConnect v2.
7. Аудит контрактов и криптографических реализаций — обязательный этап. MPC-библиотеки имеют известные уязвимости (GG18 подвержен атаке при malicious participant без abort protocol). Используем библиотеки с актуальными security review (CGGMP21). Опыт прохождения аудитов у Certik, Hacken, Trail of Bits — подтверждаем сертификатами.

Что входит в работу (deliverables)

• Исходные коды смарт-контрактов (Solidity/Rust) с документацией
• Backend-сервис MPC-координации (на Go или Rust) с API
• Мобильное приложение (iOS/Android) или браузерное расширение
• Интеграция с WalletConnect, Ledger/Trezor (по необходимости)
• Подготовка к аудиту безопасности (отчёт со списком уязвимостей)
• Документация администратора и пользователя
• Доступ к репозиторию, CI/CD, мониторинг (Tenderly, Etherscan API)
• Обучение вашей команды (2-3 сессии)
• Поддержка после запуска — 1 месяц

Сроки и стоимость

Стоимость рассчитывается индивидуально под ваш проект. Оценим за 1 день — напишите на почту или в Telegram. Предоставляем гарантию на код и timeline.

Типичные ошибки при разработке криптокошельков (и как их избежать)

• Использование устаревших MPC-библиотек — GG18 без abort protocol. Выбираем CGGMP21 или tss-lib с актуальными audit report.
• Жёсткая привязка к одному блокчейну — не закладывают абстракцию под L2/сайдчейны. Используем viem/wagmi для кросс-чейн.
• Игнорирование MEV-атак — при использовании мультисига без таймлоков. Добавляем tx simulation (Tenderly) и sandwitching protection.
• Отсутствие fallback-механизма восстановления — для Account Abstraction не настраивают social recovery. Закладываем с первого релиза.

Устраняем эти грабли на этапе проектирования — под каждый проект составляем threat model и security checklist.

Нужен надёжный кошелёк без компромиссов? Получите консультацию нашего архитектора — разберём вашу задачу и предложим архитектуру с точной сметой. Оставляйте заявку — ответим в течение дня.