Разработка браузерного расширения-кошелька

Разработка кастодиального кошелька

Кастодиальный кошелёк — это система, где приватные ключи пользователей хранятся и управляются сервисом. Пользователь аутентифицируется через логин/пароль (или OAuth), а не через seed phrase. Биржи (Binance, Coinbase), платёжные сервисы (MoonPay), корпоративные treasury решения — все работают по кастодиальной модели.

Кастодиальная модель проще для пользователей и неизбежна для массового adoption: объяснить seed phrase среднему пользователю — задача нерешённая. Но за эту простоту платит сервис: ответственность за сохранность ключей, соответствие регуляторным требованиям (VASP, custody licensing) и мишень для взломщиков — ключи хранятся централизованно.

Архитектура ключевого хранилища

HSM как основа безопасности

Hardware Security Module (HSM) — специализированное оборудование для хранения и использования криптографических ключей. Ключи никогда не покидают HSM в открытом виде: все операции подписи происходят внутри защищённого чипа.

Уровни HSM:

• AWS CloudHSM / Azure Dedicated HSM — облачные HSM с FIPS 140-2 Level 3 сертификацией. Хорошо масштабируются, управляются через API
• Thales Luna HSM — on-premise HSM, физический контроль. Требуется для строгих compliance требований
• Ledger Vault / Fireblocks — специализированные crypto custody продукты с HSM + MPC внутри

Для большинства проектов: AWS CloudHSM или аналог — разумный выбор. Он даёт hardware-grade безопасность без необходимости поддерживать физическую инфраструктуру.

MPC (Multi-Party Computation) вместо single-key

Современный стандарт для кастодиального хранения — MPC, а не классический HSM с одним ключом. MPC разделяет приватный ключ на shares между несколькими участниками (например, 2 из 3): клиентский сервер, backup сервер, сам пользователь. Ни один участник не знает полного ключа. Подпись генерируется через протокол без реконструкции ключа.

Преимущества MPC над multisig:

• Одна blockchain транзакция (multisig — несколько signatures в одной tx, дороже по газу для legacy chains)
• Нет on-chain следов распределённости (для privacy)
• Работает с любым блокчейном без изменений протокола

Библиотеки: Fireblocks MPC SDK, ZenGo's open-source TSS libraries, tss-lib (Go).

Иерархия ключей (HD Wallet)

BIP-32/BIP-44 стандарт: из одного master seed генерируется дерево ключей. Для кастодиального сервиса с миллионами пользователей не нужно хранить отдельный ключ для каждого пользователя.

Master Seed (в HSM)
└── m/44'/60'/0'  (Ethereum account 0)
    └── m/44'/60'/0'/0  (external chain)
        ├── m/44'/60'/0'/0/0  (пользователь 1)
        ├── m/44'/60'/0'/0/1  (пользователь 2)
        └── m/44'/60'/0'/0/N  (пользователь N)

Master seed хранится в HSM. Деривация дочерних ключей выполняется через HSM API. Приватные ключи конкретных пользователей — производные и не хранятся отдельно; они вычисляются из master seed + derivation path при необходимости подписи.

Важно: derivation path для каждого пользователя должен быть записан в базе данных. Потеря этого маппинга = потеря доступа к адресам.

Архитектура сервиса

Компоненты системы

Key Management Service (KMS): изолированный сервис, единственный имеющий доступ к HSM. Принимает запросы на подпись транзакций. Не хранит состояние пользователей — только генерирует подписи.

Transaction Service: обрабатывает запросы пользователей на отправку транзакций. Проводит валидацию, rate limiting, fraud detection. После approval — отправляет запрос подписи в KMS.

User Account Service: управление пользователями, балансами, историей транзакций. Хранит адреса и derivation paths.

Blockchain Gateway: мониторинг incoming транзакций, broadcast signed transactions, получение подтверждений.

User → API Gateway → Transaction Service → [fraud check + approval]
                                          → KMS (sign request)
                                          → Blockchain Gateway (broadcast)

Разделение сервисов критично: компрометация Transaction Service не даёт доступа к ключам — KMS принимает подписанные запросы только от авторизованных internal сервисов через mutual TLS.

Approval workflow

interface TransactionRequest {
    userId: string;
    toAddress: string;
    amount: string;
    token: string;
    chainId: number;
    userSignature?: string; // подпись пользователя для подтверждения
}

class TransactionApprovalService {
    async process(request: TransactionRequest): Promise<ApprovalResult> {
        // 1. Базовая валидация
        await this.validateAddress(request.toAddress);
        await this.validateBalance(request.userId, request.amount, request.token);
        
        // 2. Risk scoring
        const riskScore = await this.riskEngine.score(request);
        
        if (riskScore > HIGH_RISK_THRESHOLD) {
            // Требуем дополнительное подтверждение
            await this.requireAdditionalAuth(request.userId);
        }
        
        if (riskScore > BLOCK_THRESHOLD) {
            await this.flagForManualReview(request);
            return { status: 'PENDING_REVIEW' };
        }
        
        // 3. Rate limiting
        await this.checkRateLimits(request.userId, request.amount);
        
        // 4. Запрос подписи у KMS
        const signedTx = await this.kms.sign({
            derivationPath: await this.getUserDerivationPath(request.userId),
            transaction: await this.buildTransaction(request)
        });
        
        return { status: 'APPROVED', signedTx };
    }
}

Risk engine

Fraud detection для кастодиального кошелька — отдельный критический компонент.

Сигналы для повышения risk score:

• New device fingerprint — первый вход с нового устройства + крупная транзакция
• Unusual geography — транзакция из страны, никогда не наблюдавшейся в истории
• Velocity anomaly — 10 транзакций за 5 минут при обычной частоте 1/день
• Address risk — получатель в blacklist (Chainalysis, Elliptic)
• Amount anomaly — сумма значительно превышает среднюю по историй

class RiskEngine {
    async score(request: TransactionRequest): Promise<number> {
        const signals = await Promise.all([
            this.checkAddressReputation(request.toAddress),    // Chainalysis API
            this.checkVelocity(request.userId),
            this.checkAmountAnomaly(request.userId, request.amount),
            this.checkGeography(request.userId),
            this.checkDeviceFingerprint(request.userId)
        ]);
        
        // Взвешенная сумма сигналов
        return signals.reduce((total, signal) => 
            total + signal.score * signal.weight, 0
        );
    }
}

Регуляторные требования

Кастодиальный кошелёк — это как правило VASP (Virtual Asset Service Provider) по FATF стандартам. Требования:

Travel Rule (FATF Recommendation 16): для транзакций выше порога (1000 USD/EUR в большинстве юрисдикций) — передача информации об отправителе и получателе вместе с транзакцией. Протоколы: IVMS101 (стандарт данных), TRP (Travel Rule Protocol), OpenVASP.

KYC/AML: верификация личности пользователей, мониторинг транзакций на подозрительную активность, отчётность в финансовые органы.

Custody licensing: в ряде юрисдикций (EU, UK, некоторые штаты USA) хранение crypto активов клиентов требует специальной лицензии. MiCA (Markets in Crypto-Assets, EU) вводит требования к crypto custody providers с 2024–2025 года.

Это означает: архитектура кастодиального решения должна проектироваться с учётом compliance с первого дня, а не добавляться позже.

Операционная безопасность

Disaster recovery

Потеря master seed = потеря всех пользовательских средств. Backup стратегия:

• Geographic distribution: backup copies master seed (зашифрованы) хранятся в физически разных HSM в разных регионах
• Shamir's Secret Sharing: master seed разделён на N shares, минимум K необходимо для восстановления. K shares хранятся у разных доверенных лиц / в разных локациях
• Recovery drill: регулярные тесты процедуры восстановления (quarterly)

Key rotation

Периодическая ротация operational ключей (не master seed, а ключи доступа к HSM API, сервисные ключи). Master seed ротируется через миграцию: генерация нового seed, деривация новых адресов, постепенный перевод средств.

Incident response план

Что делать при подозрении на компрометацию:

1. Немедленный freeze withdrawal (pause в Transaction Service)
2. Ротация API ключей и сервисных credentials
3. Аудит access logs за период
4. Уведомление пользователей и регулятора (если требуется)

Стек и сроки

Backend: Node.js / Go + PostgreSQL + Redis (rate limiting, session). KMS: интеграция с AWS CloudHSM через PKCS#11. Blockchain: viem (EVM), @solana/web3.js, bitcoinjs-lib для мультичейн. MPC: опционально — интеграция Fireblocks API или open-source TSS. Compliance: интеграция Chainalysis KYT для address screening.

MVP (Ethereum + ERC-20, базовый risk engine): 8–10 недель. Production с multichian, MPC и compliance интеграцией: 4–6 месяцев.

Стоимость зависит от количества поддерживаемых сетей, требований к compliance и объёма ожидаемой нагрузки.