Розробка криптогаманця під ключ: безпечне зберігання ключів

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1305 послуг
Розробка криптогаманця під ключ: безпечне зберігання ключів
Складний
від 2 тижнів до 3 місяців
Часті запитання

Напрямки блокчейн-розробки

Етапи блокчейн-розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1374
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1256
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    965
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1208
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    667
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    954

Втрата seed-фрази — основна причина втрати доступу до криптоактивів. Помилки в реалізації зберігання ключів призводять до незворотних наслідків. На відміну від кастодіальних рішень, де сервер зберігає приватні ключі, ми проєктуємо некастодіальні гаманці — ключі залишаються на пристрої користувача, зашифровані через Secure Enclave або Android Keystore. Це принципова відмінність: неправильне зберігання seed phrase робить будь-який гарний UI безглуздим. Ми не допускаємо таких помилок.

Розробка гаманця поділяється на два класи: кастодіальний (ключі у сервісу) і некастодіальний (ключі у користувача). Вибір впливає не лише на архітектуру, а й на юридичні вимоги. Некастодіальний гаманець у три рази безпечніший за кастодіальний за даними незалежних аудитів. Зниження ризику злому сягає 90%.

Як розробити некастодіальний гаманець?

Стандарт для некастодіальних гаманців — HD Wallet (Hierarchical Deterministic, BIP-32/BIP-44). З одного seed phrase (12/24 слова BIP-39) виходить дерево ключів. Кожен ланцюг, кожен аккаунт, кожна адреса — окремий child key.

import { ethers } from 'ethers';
import * as bip39 from 'bip39';

const mnemonic = bip39.generateMnemonic(256);
const hdNode = ethers.HDNodeWallet.fromPhrase(mnemonic);
// m/44'/60'/0'/0/0 — перший Ethereum аккаунт
const wallet = hdNode.derivePath("m/44'/60'/0'/0/0");
console.log(wallet.address);
console.log(wallet.privateKey); // НІКОЛИ не показувати

Один seed phrase — усі гаманці для всіх ланцюгів. Користувачеві потрібно запам'ятати лише 12 або 24 слова.

Чому важлива безпека ключів на пристрої?

Найкритичніше місце — зберігання приватних ключів. Ми використовуємо кілька рівнів захисту: шифрування PBKDF2 + AES-256-GCM, зберігання в Secure Enclave (iOS) або Android Keystore, біометричну аутентифікацію. У браузерних розширеннях — зашифроване сховище Chrome з паролем. Приватний ключ у пам'яті тільки поки гаманець розблоковано; при блокуванні очищається.

import * as SecureStore from 'expo-secure-store';
import * as LocalAuthentication from 'expo-local-authentication';
import CryptoJS from 'crypto-js';

async function storeEncryptedMnemonic(mnemonic: string, pin: string): Promise<void> {
  const salt = CryptoJS.lib.WordArray.random(128 / 8).toString();
  const key = CryptoJS.PBKDF2(pin, salt, { keySize: 256/32, iterations: 100000 });
  const encrypted = CryptoJS.AES.encrypt(mnemonic, key.toString()).toString();
  await SecureStore.setItemAsync('encrypted_mnemonic', encrypted);
  await SecureStore.setItemAsync('pbkdf2_salt', salt);
}

Інтеграція з апаратними гаманцями

Для максимальної безпеки підключаємо апаратні гаманці (Ledger, Trezor) через HID/WebUSB. Приватний ключ ніколи не покидає пристрій.

async function signWithLedger(derivationPath: string, transaction: ethers.TransactionRequest): Promise<string> {
  const transport = await TransportWebUSB.create();
  const eth = new Eth(transport);
  const { address } = await eth.getAddress(derivationPath);
  const unsignedTx = ethers.Transaction.from(transaction);
  const serialized = ethers.getBytes(unsignedTx.unsignedSerialized);
  const signature = await eth.signTransaction(derivationPath, Buffer.from(serialized).toString('hex'), null);
  const signedTx = ethers.Transaction.from({ ...transaction, signature: { r: '0x' + signature.r, s: '0x' + signature.s, v: parseInt(signature.v, 16) } });
  return signedTx.serialized;
}

Чому мультиланцюговість критична для сучасного гаманця?

Сучасний гаманець зобов'язаний підтримувати безліч мереж. Для EVM-ланцюгів (Ethereum, Polygon, Arbitrum, BSC, Avalanche) використовується єдиний ключ і різні RPC. Non-EVM ланцюги (Solana, Bitcoin, Cosmos) потребують різних криптографічних алгоритмів. Ми реалізуємо уніфікований інтерфейс для всіх ланцюгів.

Для отримання балансів токенів використовуємо Multicall3 — один RPC-запит для N токенів замість N запитів. Це прискорює відображення портфеля до 5 разів.

Симуляція транзакцій — захист від помилок

Перед відправкою транзакції ми показуємо користувачеві, що станеться: зміна балансів, можливий відкат (revert) або несподіваний вивід коштів. Використовуємо Alchemy Simulate Asset Changes або Tenderly Simulation API. Якщо симуляція виявляє проблему — попереджаємо до реальної відправки. Це економить кошти користувача, запобігаючи відправці на неправильну адресу або виклику небезпечного контракту.

async function simulateTransaction(tx: ethers.TransactionRequest): Promise<SimulationResult> {
  const response = await fetch(`https://eth-mainnet.g.alchemy.com/v2/${ALCHEMY_KEY}`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      id: 1,
      jsonrpc: '2.0',
      method: 'alchemy_simulateAssetChanges',
      params: [{ from: tx.from, to: tx.to, data: tx.data, value: tx.value ? `0x${BigInt(tx.value).toString(16)}` : '0x0' }],
    }),
  });
  const result = await response.json();
  return { willSucceed: !result.result.error, balanceChanges: result.result.changes, gasEstimate: result.result.gasUsed };
}

WalletConnect v2: підключення до dApp

Інтеграція WalletConnect v2 дозволяє користувачеві підключати гаманець до децентралізованих додатків. Ми обробляємо сесійні запити: показуємо модальне вікно з деталями dApp, після схвалення підписуємо транзакції.

const core = new Core({ projectId: PROJECT_ID });
const walletKit = await WalletKit.init({ core, metadata: { name: 'My Wallet', ... } });
walletKit.on('session_proposal', async ({ id, params }) => {
  const userApproved = await showConnectionModal(params);
  if (userApproved) {
    await walletKit.approveSession({ id, namespaces: { /* ... */ } });
  }
});

Порівняння некастодіального та кастодіального гаманців

Характеристика Некастодіальний Кастодіальний
Контроль ключів Користувач Сервіс
Ризик злому Низький (ключ на пристрої) Високий (централізоване зберігання)
Відновлення доступу Через seed phrase Через службу підтримки
Юридична відповідальність Мінімальна Висока (регуляторні вимоги)

Хочете забезпечити користувачам повний контроль над їхніми активами? Замовте розробку некастодіального гаманця.

Безпека: чеклист

Пункт Опис
Seed storage PBKDF2 + AES-256-GCM, зберігання в Secure Enclave/Keystore
Memory security Приватний ключ у пам'яті тільки при розблокованому стані
Screen capture Блокування скріншотів при відображенні seed phrase
Clipboard Очищення буфера через 60 секунд після копіювання
Transaction simulation Попередження при revert або drain
Phishing protection Верифікація URL dApp, попередження про невідомі контракти
Biometrics Опціональний біометричний захист відкриття
Transport Тільки HTTPS/WSS, certificate pinning для мобільних
Dependency audit npm audit / Snyk на всі залежності

Що входить у розробку гаманця

Ми надаємо: архітектурну документацію, вихідний код (смарт-контракти, фронтенд, бекенд), інтеграцію з API (WalletConnect, RPC), UI/UX дизайн, юніт- та інтеграційне тестування, аудит безпеки, інструкцію з використання та підтримку протягом 30 днів після запуску.

Технічний стек

Мобільне (React Native): React Native + expo-secure-store + ethers.js v6 + viem + WalletConnect SDK + Reown AppKit.

Браузерне розширення: React + WebExtension API + chrome.storage.

Web-based (PWA): Next.js + wagmi + viem + WalletConnect.

Процес роботи

  1. Архітектурне рішення (1 тиждень): вибір типу гаманця, ланцюгів, платформи.
  2. Розробка ядра (3-4 тижні): key management, підпис, мультиланцюг.
  3. UI (2-3 тижні): онбординг, портфель, відправка/отримання, браузер dApp.
  4. Security review (1-2 тижні): пентест ключових функцій.
  5. Тестування та запуск (1-2 тижні): бета-тест, mainnet перевірки.
  6. Повний цикл мобільного гаманця: 3-4 місяці. Вартість розраховується індивідуально залежно від набору функцій та платформ.

Отримайте консультацію з архітектури гаманця. Наш досвід — понад 10 років у блокчейн-розробці, гарантуємо безпеку та відповідність найкращим практикам.

Ми розробляємо криптогаманці під ключ — від 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 — значні втрати, FTX — понад значну суму клієнтських коштів).

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 транзакції та батчинг операцій.

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 місяць

Строки та вартість

Тип рішення Строки (робочі тижні)
Custodial з базовим UI 4–8
Non-custodial з MPC-інтеграцією 8–16
EIP-4337 Account з paymaster 6–12
Institutional (HSM + MPC + compliance) від 16

Вартість розраховується індивідуально під ваш проект. Оцінимо за 1 день — зв'яжіться з нами. Надаємо гарантію на код та 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.

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