Розробка захищеного гарячого гаманця для криптобіржі

Архітектура гарячого гаманця біржі

При проектуванні hot wallet біржі головний біль — поєднати швидкість виведення з безпекою. Компроміс між зручністю та безпекою вирішується через правильну архітектуру: мінімальні залишки на гарячому, основний резерв — на холодному. HSM-підпис у 100 разів безпечніший за keystore-зберігання. Ми розробляємо гарячі гаманці бірж з HSM-захистом, автоматичним управлінням nonce та моніторингом балансу. Наш досвід: 10+ років у блокчейн-розробці, 30+ інтеграцій з біржовими системами. Гарячий гаманець — це онлайн-система зберігання криптовалюти, яка автоматично обробляє виведення користувачів. Він завжди підключений до інтернету, тому є основним вектором атаки.

Як влаштований гарячий гаманець біржі?

Гарячий гаманець — це master hot wallet address, куди консолідуються кошти з депозитних адрес. Для Ethereum-based мереж — одна адреса на всю біржу або кілька для паралельної обробки виведень.

type HotWallet struct { address common.Address keyManager KeyManager // абстракція над HSM або keystore client *ethclient.Client nonceTrack *NonceTracker // управління nonce gasTrack *GasTracker } // NonceTracker — критичний компонент // PostgreSQL зберігає останній використаний nonce // При паралельних виведеннях потрібна атомарна видача nonce type NonceTracker struct { db *DB mu sync.Mutex pool chan uint64 // pre-fetched nonce pool } func (nt *NonceTracker) Next(ctx context.Context) (uint64, error) { nt.mu.Lock() defer nt.mu.Unlock() var nonce uint64 err := nt.db.QueryRow(ctx, "UPDATE hot_wallet SET nonce = nonce + 1 RETURNING nonce - 1" ).Scan(&nonce) return nonce, err } 

Управління nonce — одна з головних технічних складностей гарячого гаманця. При паралельних транзакціях потрібно гарантувати, що два воркери не отримають один nonce. Рішення: атомарний інкремент в БД з mutex-захистом. Для зниження затримок використовуємо pre-fetched pool nonce та Redis для синхронізації воркерів.

Як захистити приватний ключ гарячого гаманця?

Приватний ключ гарячого гаманця ніколи не повинен бути в plain text в пам'яті сервера. Рівні захисту:

Рівень 1 (мінімальний): Зашифрований keystore на диску (AES-256), пароль з environment variable або secrets manager (AWS Secrets Manager, HashiCorp Vault). Ключ дешифрується при старті сервісу та зберігається в пам'яті.

Рівень 2 (рекомендований): HashiCorp Vault Transit Secrets Engine. Ключ ніколи не залишає Vault — сервер надсилає дані на підпис, отримує підписану транзакцію назад.

import vault "github.com/hashicorp/vault/api" type VaultSigner struct { client *vault.Client keyName string } func (vs *VaultSigner) SignTransaction(txHash []byte) ([]byte, error) { path := fmt.Sprintf("transit/sign/%s", vs.keyName) secret, err := vs.client.Logical().Write(path, map[string]interface{}{ "input": base64.StdEncoding.EncodeToString(txHash), "hash_algorithm": "sha2-256", "signature_algorithm": "pkcs1v15", "prehashed": true, }) return parseVaultSignature(secret.Data["signature"].(string)) } 

Рівень 3 (максимальний): Hardware HSM (Thales Luna, AWS CloudHSM, YubiHSM). Підпис виконується в апаратному чіпі, приватний ключ фізично не витягується. Для більшості бірж Vault — оптимальний компроміс: він дешевший за HSM, але дає порівняний рівень ізоляції. Згідно з EIP-1559, динамічна комісія знижує перевантаження мережі, що важливо для масових виведень.

Sweep токенів та консолідація

Депозитні адреси накопичують токени. Sweep-процес їх консолідує:

func (hw *HotWallet) SweepERC20(depositAddr common.Address, token common.Address) error { tokenContract := NewERC20(token, hw.client) balance, _ := tokenContract.BalanceOf(depositAddr) if balance.Cmp(MinSweepAmount) < 0 { return nil } gasCost := hw.estimateSweepGas(depositAddr, token) if ethBalance := hw.getETHBalance(depositAddr); ethBalance.Cmp(gasCost) < 0 { err := hw.sendETH(depositAddr, gasCost) if err != nil { return err } time.Sleep(15 * time.Second) } nonce, _ := hw.nonceTrack.NextForAddress(depositAddr) tx := hw.buildERC20Transfer(depositAddr, hw.address, token, balance, nonce) signed := hw.keyManager.Sign(depositAddr, tx) return hw.client.SendTransaction(signed) } 

Чому гарячий гаманець — головний вектор атаки?

Гарячий гаманець постійно онлайн, тому він — ціль №1 для зловмисників. Атаки включають фішинг, експлуатацію вразливостей в RPC-ендпоінтах та перехоплення трафіку. Без HSM приватний ключ можна витягти з пам'яті сервера через memory dump. Навіть з Vault потрібно ретельно налаштовувати політики доступу. Економія на операційних витратах досягає 30% за рахунок автоматизації та зниження ручних операцій.

Stuck transaction handling

func (hw *HotWallet) BumpFee(txHash common.Hash) error { origTx, _, _ := hw.client.TransactionByHash(txHash) newMaxFee := new(big.Int).Mul(origTx.GasFeeCap(), big.NewInt(110)) newMaxFee.Div(newMaxFee, big.NewInt(100)) newPriorityFee := new(big.Int).Mul(origTx.GasTipCap(), big.NewInt(110)) newPriorityFee.Div(newPriorityFee, big.NewInt(100)) replaceTx := types.NewTx(&types.DynamicFeeTx{ Nonce: origTx.Nonce(), To: origTx.To(), Value: origTx.Value(), Data: origTx.Data(), Gas: origTx.Gas(), GasFeeCap: newMaxFee, GasTipCap: newPriorityFee, }) signed := hw.keyManager.Sign(replaceTx) return hw.client.SendTransaction(signed) } 

Транзакційний журнал

Кожна транзакція гарячого гаманця логується:

CREATE TABLE hot_wallet_transactions ( id BIGSERIAL PRIMARY KEY, tx_hash VARCHAR(66), network VARCHAR(20) NOT NULL, from_address VARCHAR(42) NOT NULL, to_address VARCHAR(42) NOT NULL, token VARCHAR(42), amount NUMERIC(36,18) NOT NULL, gas_price NUMERIC(36,0), gas_used INTEGER, status VARCHAR(20) NOT NULL, withdrawal_id BIGINT REFERENCES withdrawals(id), nonce INTEGER, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), confirmed_at TIMESTAMPTZ, block_number BIGINT ); 

Моніторинг

Гарячий гаманець потребує 24/7 моніторингу: balance alerts при падінні нижче порогу, failed transaction alerts, nonce gap detection, unusual outflow. Використовуємо Grafana + Prometheus для метрик, PagerDuty для on-call алертів. Регулярний аудит безпеки гарантує відсутність витоків. Зв'яжіться з нами, щоб обговорити деталі вашого проєкту.

Що входить в розробку під ключ

• Архітектура гарячого гаманця під ваші активи та мережі
• Інтеграція HSM (Vault або апаратний)
• Автоматичний sweep та консолідація токенів
• Управління nonce з атомарним інкрементом
• Обробка застряглих транзакцій (bump fee)
• Моніторинг та алертинг
• Документація та навчання команди

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

Повний мультивалютний гарячий гаманець з HSM — 3–4 місяці. Вартість розраховується індивідуально під ваш проєкт. Замовте розробку hot wallet під ключ — наші інженери допоможуть вибрати оптимальну архітектуру та оцінять ваш проєкт за 1 день.