Розробка браузерного розширення-гаманця

Розробка кастодіального гаманця

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

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

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

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

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

Рівні HSM:

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

Для більшості проектів: AWS CloudHSM або аналог — розумний вибір. Hardware-grade безпека без підтримки інфраструктури.

MPC замість одиночного ключа

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

Переваги MPC над multisig:

• Одна blockchain транзакція (multisig — кілька підписів, більше газу на legacy ланцюгах)
• Немає on-chain слідів розподіленості (для privacy)
• Працює з будь-яким блокчейном без змін протоколу

Бібліотеки: Fireblocks MPC SDK, ZenGo's open-source TSS, 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  (user 1)
        ├── m/44'/60'/0'/0/1  (user 2)
        └── m/44'/60'/0'/0/N  (user 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: моніторинг вхідних транзакцій, broadcast підписаних, отримання підтверджень.

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

Поділ сервісів критичний: компрометація Transaction Service не дає доступу до ключів — KMS приймає запити тільки від авторизованих внутрішніх сервісів через mutual TLS.

Workflow затвердження

interface TransactionRequest {
    userId: string;
    toAddress: string;
    amount: string;
    token: string;
    chainId: number;
}

class TransactionApprovalService {
    async process(request: TransactionRequest): Promise<ApprovalResult> {
        await this.validateAddress(request.toAddress);
        await this.validateBalance(request.userId, request.amount, request.token);
        
        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' };
        }
        
        await this.checkRateLimits(request.userId, request.amount);
        
        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:

• Новий device fingerprint — перший вхід з нового пристрою + крупна транзакція
• Незвична географія — транзакція з країни яка ніколи не спостерігалася
• Velocity anomaly — 10 транзакцій за 5 хвилин при звичайній частоті 1/день
• Ризик адреси — отримувач у blacklist (Chainalysis, Elliptic)
• Anomaly суми — сума значно перевищує середню за історією

class RiskEngine {
    async score(request: TransactionRequest): Promise<number> {
        const signals = await Promise.all([
            this.checkAddressReputation(request.toAddress),
            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) зберігання крипто активів клієнтів вимагає спеціальної ліцензії. MiCA (Markets in Crypto-Assets, EU) вводить вимоги до крипто-кастодіальних провайдерів 2024–2025.

Архітектура повинна проектуватися для compliance з першого дня, не додаватися пізніше.

Операційна безпека

Disaster recovery

Втрата master seed = втрата всіх коштів користувачів. Backup стратегія:

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

Key rotation

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

Incident response план

Що робити при підозрі на компрометацію:

1. Негайне заморозження withdrawal
2. Ротація API ключів
3. Аудит access logs
4. Уведомлення користувачів та регулятора (якщо потрібно)

Стек та графік

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

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

Вартість залежить від кількості підтримуваних мереж, вимог compliance та очікуваного навантаження.