Разработка мультичейн-кошелька с поддержкой EVM, Solana, Cosmos

Разработка криптокошелька, поддерживающего несколько сетей, — это не просто «подключить несколько сетей». Это комплексная система, которая должна корректно обрабатывать принципиально разные блокчейн-архитектуры: EVM-совместимые цепи (Ethereum, Arbitrum, Polygon, BSC), EVM-несовместимые (Solana, Sui, Aptos), Bitcoin с UTXO-моделью, Cosmos экосистему с IBC. Каждая имеет свою криптографию, формат транзакций, fee-механизм и модель аккаунтов. Без грамотной абстракции поддержка каждой новой сети превращается в переписывание половины кодовой базы — именно так рождаются баги и затягиваются сроки. Дополнительно встают вопросы gas optimization: в EVM-сетях стоимость транзакции зависит от газа, а в Solana — от приоритета, что требует разных стратегий оценки комиссии.

Мы решаем эту проблему с помощью Chain Abstraction Layer — единого интерфейса для всех сетей. Это позволяет добавить новую цепь за 1-2 недели вместо 2-3 месяцев. На практике это означает экономию до 40% на каждой интеграции. Такой подход в 3 раза быстрее ручной реализации. Оценим ваш проект за 2 дня — свяжитесь с нами.

Как работает деривация ключей в мультичейн кошельке?

Все современные мультичейн кошельки строятся на BIP-32/BIP-39/BIP-44 стандартах. Одна seed-фраза (12-24 слова) → один мастер ключ → дерево дочерних ключей для каждой сети. Стандарт BIP-44 определяет путь деривации: m / purpose' / coin_type' / account' / change / index. Путь состоит из 5 уровней: purpose (фиксирован 44'), coin_type (например, 0 для Bitcoin, 60 для Ethereum, 501 для Solana), account, change (0 для внешних, 1 для сдачи), index (адреса). Это позволяет восстанавливать все ключи из одной seed-фразы.

import { HDNodeWallet, Mnemonic } from 'ethers';
import { derivePath } from 'ed25519-hd-key';
import * as bip39 from 'bip39';

const mnemonic = Mnemonic.fromEntropy(crypto.getRandomValues(new Uint8Array(16)));
const seed = await bip39.mnemonicToSeed(mnemonic.phrase);

const evmWallet = HDNodeWallet.fromSeed(seed).derivePath("m/44'/60'/0'/0/0");
console.log('EVM address:', evmWallet.address);

const solanaPath = "m/44'/501'/0'/0'";
const { key: solanaPrivKey } = derivePath(solanaPath, seed.toString('hex'));

Что такое Chain Abstraction Layer?

Архитектура мультичейн кошелька строится на адаптерах — объектах, единообразно работающих с разными сетями. Это ключевая абстракция, скрывающая различия в криптографии, форматах транзакций и RPC.

interface ChainAdapter {
    chainId: string;
    chainName: string;
    getAddress(publicKey: Uint8Array): string;
    getBalance(address: string): Promise<bigint>;
    buildTransaction(params: TxParams): Promise<UnsignedTx>;
    signTransaction(tx: UnsignedTx, privateKey: Uint8Array): Promise<SignedTx>;
    broadcastTransaction(tx: SignedTx): Promise<string>;
    getTransactionStatus(txHash: string): Promise<TxStatus>;
    estimateFee(tx: UnsignedTx): Promise<FeeEstimate>;
}

class EVMAdapter implements ChainAdapter {
    private client: PublicClient;
    constructor(rpcUrl: string, public chainId: string, public chainName: string) {
        this.client = createPublicClient({ transport: http(rpcUrl) });
    }
    async getBalance(address: string): Promise<bigint> {
        return this.client.getBalance({ address: address as `0x${string}` });
    }
    async buildTransaction(params: TxParams): Promise<UnsignedTx> {
        const nonce = await this.client.getTransactionCount({ address: params.from as `0x${string}` });
        const feeData = await this.client.estimateFeesPerGas();
        return {
            to: params.to,
            value: params.value ?? 0n,
            data: params.data ?? '0x',
            nonce,
            maxFeePerGas: feeData.maxFeePerGas,
            maxPriorityFeePerGas: feeData.maxPriorityFeePerGas,
            chainId: BigInt(this.chainId),
        };
    }
}

Как добавить новую цепь в мультичейн кошелёк?

1. Реализовать ChainAdapter — описать кривую (secp256k1 или ed25519), формат транзакции, fee-модель.
2. Добавить путь деривации в BIP-44 — назначить coin_type (для Bitcoin — 0, Ethereum — 60, Solana — 501).
3. Протестировать подпись и отправку — проверить на testnet, убедиться, что explorer показывает транзакцию.
4. Утвердить через pull request — код-ревью и автоматические тесты (Slither, фаззинг).

Этот процесс занимает 1–2 недели вместо 2–3 месяцев при ручной реализации. Наш Chain Abstraction Layer сокращает время интеграции в 3 раза.

Безопасное хранение и подпись

На мобильных платформах используем Secure Enclave (iOS) или StrongBox (Android). Ограничение: они не поддерживают secp256k1 напрямую, поэтому seed хранится зашифрованным в Keychain с биометрией. В Web Extension приватные ключи живут только в background service worker — content script не имеет к ним доступа. Производительность подписи на мобильных устройствах выше, чем у браузерных расширений, благодаря аппаратному ускорению.

func storeSeed(_ seed: Data) throws {
    let query: [String: Any] = [
        kSecClass as String: kSecClassGenericPassword,
        kSecAttrAccount as String: "wallet_seed",
        kSecValueData as String: seed,
        kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlockedThisDeviceOnly,
        kSecAttrAccessControl as String: SecAccessControlCreateWithFlags(
            nil,
            kSecAttrAccessibleWhenUnlockedThisDeviceOnly,
            [.biometryAny, .privateKeyUsage],
            nil
        )!
    ]
    let status = SecItemAdd(query as CFDictionary, nil)
    guard status == errSecSuccess else { throw KeychainError.unhandledError(status) }
}

Token discovery и NFT

Автопоиск токенов через Etherscan, Covalent или Solana getParsedTokenAccountsByOwner. NFT — Alchemy NFT API с кэшированием IPFS metadata. Пользователю не нужно добавлять токены вручную.

WalletConnect v2

Стандартный протокол связи с dApp. Подпись транзакций через eth_sendTransaction и personal_sign. Обработка сессий в background.

Сравнение блокчейнов: EVM, Solana, Bitcoin

Стек и сроки

Минимальный production-ready мультичейн кошелёк (EVM + Solana, mobile-first) — 4–5 месяцев. Добавление Bitcoin (UTXO модель) — ещё 4–6 недель. Расширение на Cosmos — 3–4 недели через cosmjs. Стоимость рассчитывается индивидуально.

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

• Архитектурная документация и выбор стека
• Реализация HD-кошелька с BIP-44, BIP-39
• Интеграция 2+ сетей на выбор
• Интерфейс управления токенами и NFT
• Подключение WalletConnect v2
• Аудит смарт-контрактов (внешний или автоматизированный)
• Тестирование на реальных устройствах
• Передача исходников и инструкция по деплою
• Поддержка в течение 30 дней после релиза

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

Мы разрабатываем криптокошельки под ключ — от 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.

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