Розробка системи депозитів й виводів
Система депозитів й виводів — найкритичніша з точки зору безпеки частина криптобиржи. Тут зберігаються й переміщаються реальні кошти користувачів. Кожна помилка — прямі фінансові втрати. Розберемо архітектуру з акцентом на безпеку й стійкість до сбоїв.
Архітектура депозитів
Генерація депозитних адрес
Кожен користувач отримує унікальну депозитну адресу для кожної мережі. Два підходи:
HD Wallet (Hierarchical Deterministic): З одного мастер-seed генерується детерміноване дерево ключів по BIP-32/BIP-44.
Мастер-seed зберігається в HSM (Hardware Security Module) або в зашифрованому vault (HashiCorp Vault). Публічні ключі для генерації адрес — у БД, приватні ключи для підпісу — лише в HSM.
Shared address + memo: Один адрес на всю біржу, користувач вказує memo/tag при відправці. Використовується для Ripple (XRP), Stellar (XLM), Cosmos. Дешевше у обслуговуванні, але помилка в memo — потеря коштів.
Моніторинг вхідних транзакцій
Сервіс моніторингу депозитів підписується на события блокчейну.
Підтвердження й finality
Кількість потрібних підтверджень залежить від мережі й суми.
Після досягнення порога підтверджень депозит зараховується на баланс користувача. До цього — у статусі pending. Показуємо користувачу pending депозити з індикатором прогресу.
Reorg handling: зберігаємо block_hash разом з block_number. При виявленні реорга (хеш блоку змінився) — помічаємо потрагнені транзакції як reorged й переначинаємо моніторинг.
Консолідація коштів (sweeping)
Депозитні адреси — тисячи або мільйони. Зберігати ETH на кожному адресі — дорого й небезпечно. Потрібна автоматична консолідація на master hot wallet.
Для ERC20 токенів завдання ускладнене: потрібен ETH на депозитному адресі для газу. Рішення:
- Gas station: відправити ETH перед sweep, потім sweep токенів
- Gasless sweep через EIP-2612/permit: якщо токен підтримує permit, біржа платить газ
- Batch sweep через multicall: один виклик збирає кошти з кількох адрес
Архітектура виводів
Черга й апруви
Вивід проходить кілька стадій:
REQUESTED → VALIDATED → APPROVED → SIGNING → BROADCASTING → PENDING → CONFIRMED
VALIDATED: перевірка балансу, лімітів, AML/KYC. Якщо пройшов — резервуємо кошти.
APPROVED: для крупних сум — manual review оператором біржи або мультиподпись.
SIGNING: підпись транзакції в HSM або cold wallet системі. Ніколи не підписуємо на сервері, де міститься логіка апрувів.
BROADCASTING: відправка транзакції в мережу. Після цього транзакцію неможливо відмінити.
Управління газом
Біржа платить газ за виводи. Потрібна система управління газом.
Сповіщення й статусі
Користувач повинен бачити стан вивода в реальному часі:
- WebSocket push при кожній зміні статусу
- Email/Telegram сповіщення на ключових етапах
- Transaction hash з посиланням на explorer одразу після broadcast
Безпека
Критичні перевірки
Whitelist адрес: вимагати додавання нового адреса за 24–48 годин до можливості вивода на нього. При додаванні — email підтвердження + 2FA. Запобігає миттєвому виводу при компрометації аккаунта.
Anti-phishing: показувати anti-phishing код в письмах й UI.
Лімити вивода: дневні лімити по рівнях KYC. При перевищенні — manual review.
Velocity checks: кілька виводів за короткий час → тимчасова блокування й сповіщення.
Hot/Warm/Cold wallet сегрегація
- Hot wallet: невеликий оперативний запас (10–20% від дневного обсягу виводів), завжди online, автоматичні виводи
- Warm wallet: multi-sig (2-of-3 або 3-of-5 hardware keys), пополнює hot wallet раз на день
- Cold wallet: оффлайн хранення, лише для крупних резервів, ручна процедура доступу
Розподіл: 5–10% hot, 15–20% warm, 70–80% cold.
Інфраструктура й надійність
Власна нода vs API провайдер: власна повна нода дає надійність й незалежність. API провайдери (Alchemy, QuickNode, Infura) — зручність, але залежність. Для production біржи: кілька провайдерів + власна нода, автоматичний failover.
Idempotентність: кожен запит на вивід має унікальний withdrawal_id. Повторна обробка одного ID не створює дубль транзакції. Критично для відновлення після сбоїв.
Transaction monitoring: після broadcast — періодична перевірка статусу транзакції. Якщо через N хвилин не в mempool — вважаємо дропнутою, відправляємо заново з коректним nonce.
Таймлайн розробки
| Компонент | Термін |
|---|---|
| Ethereum + ERC20 депозити/виводи | 4–6 тижнів |
| Bitcoin | 3–4 тижні |
| TRON | 2–3 тижні |
| Кожна додаткова EVM-мережа | 1–2 тижні |
| Мультивалютний hot wallet менеджмент | 3–4 тижні |
| Admin dashboard для моніторингу | 2–3 тижні |
Повна система для 5-7 мереж з HSM інтеграцією, AML проверками й административным інтерфейсом — 3–5 місяців.