Розробка мобільного HD-кошелька (BIP-39/BIP-44)
Клієнт хоче зберігати кілька blockchain-акаунтів в одній програмі та давати користувачу одну seed-фразу з 12 або 24 слів. Звучить просто — поки не дійдете до деривації ключів, різних кривих (secp256k1 проти Ed25519), SLIP44-індексів монет і того, як Flutter або React Native працюють з великими цілими числами нативно.
Чому "просто генерувати ключі" не працює
BIP-39 — стандарт мнемоніки. Беріть 128 або 256 бітів ентропії, додайте контрольну суму, розбийте на 11-бітні групи, маппуйте на wordlist (англійська — еталон, інші мови — опціональний бонус). З мнемоніки через PBKDF2-HMAC-SHA512 із сіллю "mnemonic" + passphrase та 2048 ітерацій — отримайте 512-бітний seed.
Потім BIP-32: з seed через HMAC-SHA512 — master private key + master chain code. Всі дерево будується рекурсивно — child key derivation через hardened (індекс ≥ 0x80000000) або normal шляхи. Hardened derivation важлива: normal derivation утічки child private key + chain code дозволяє відновити parent key. Account-рівень (m/44'/coin'/account') — hardened обов'язкова.
BIP-44 фіксує шлях: m / 44' / coin_type' / account' / change / address_index. Ethereum coin_type = 60, Bitcoin = 0, Solana — 501. Не деталі — це те, по чому ваш кошелек повинен бути сумісним з MetaMask, Trust Wallet, Ledger Live.
Де реально ломається при мобільній реалізації
BigInt та нативні бібліотеки. JavaScript в React Native не має нативного BigInt до Hermes 0.11+. Бібліотека @scure/bip32 використовує noble-curves, що вимагає BigInt. На старих Hermes-збірках програма крашується при першій деривації з ReferenceError: BigInt is not defined. Рішення — явний polyfill або перехід на react-native-quick-crypto + нативний модуль.
Тестування сумісності. Тестові вектори з спецификацій BIP-39 та BIP-32 — обов'язкова частина тест-сьюту. Якщо ваш mnemonicToSeed("abandon abandon ... about") не видає c55257... з офіційного вектора — баг у PBKDF2. Не очевидно при ручному тестуванні.
Solana та Ed25519. Solana використовує SLIP-0010 деривацію для Ed25519, а не стандартну BIP-32. @solana/web3.js Keypair.fromSeed() бере 32 байти, а не extended key. Шлях m/44'/501'/0'/0' — весь hardened, normal derivація для Ed25519 не визначена. Мішання secp256k1 та Ed25519 в одному HD-дереві без урахування — джерело невірних адрес.
Flutter. Пакет bip39 на pub.dev заброшен з 2021 року. bip_wallet працює, але не покриває Solana. Для production збирайте нативний плагін через platform channels: Swift/Kotlin реалізація через WalletCore від Trust Wallet — там є BIP-39, SLIP-0010, підтримка 60+ монет з правильними coin_type індексами.
Як будуємо реалізацію
Основа на iOS — WalletCore (C++/Swift) через Swift Package Manager. На Android — той самий WalletCore через JNI або bitcoinj для Bitcoin-специфічної частини. Ентропія з SecRandomCopyBytes (iOS) або SecureRandom (Android) — не з Math.random() та не з часу.
Структура кошелька в пам'яті:
HDWallet
├── mnemonic: String (тільки в пам'яті, ніколи у UserDefaults/SharedPreferences)
├── seed: Data (512 бітів, ephemeral)
└── accounts: [CoinType: [HDAccount]]
├── ETH: account 0 → m/44'/60'/0'
├── BTC: account 0 → m/44'/0'/0'
└── SOL: account 0 → m/44'/501'/0'/0'
Приватні ключі живуть у Secure Enclave (iOS) або StrongBox (Android) після первинної деривації. Seed та мнемоніка знищені з пам'яті через Data.resetBytes / Arrays.fill(seed, 0).
Для мультиаккаунту інкрементуйте account' індекс у шляху BIP-44, не address_index. MetaMask використовує address_index, Trust Wallet — account'. Обидва валідні, взаємно несумісні — зафіксуйте у вимогах перед стартом.
Процес
Почніть з аудиту вимог: які монети, які derivation paths потрібні, потрібна ли сумісність з конкретним зовнішнім кошельком. Потім — виберіть крипто-бібліотеку (WalletCore, noble-curves + polyfills, bitcoinj), напишіть unit-тести на BIP-32/BIP-39 офіційні вектори, нативна реалізація генерації ентропії, інтеграція з Secure Enclave/StrongBox для зберігання, UI-шар з підтвердженням seed.
Окремий етап — тестування відновлення: seed-фраза → ті ж адреси. Тестуйте на реальному пристрої, не тільки в симуляторі.
Часова шкала — від 1 тижня (один блокчейн, React Native + Hermes, без Secure Enclave) до 3 місяців (мультичейн, Flutter, нативні плагіни, повний аудит безпеки). Вартість індивідуальна після аналізу вимог.