Реалізація адресної книги криптоадрес у мобільному гаманці
При розробці мобільного криптогаманця ми зіткнулися з типовою болем: адресна книга — це не просто список рядків. Помилка в адресі призводить до безповоротної втрати коштів. За статистикою, близько 5% усіх транзакцій з помилками в адресах становить людський фактор — помилки, неправильна вставка з буфера обміну, ігнорування checksum. Наша команда з 5+ років досвіду в крипторозробці (понад 50 реалізованих проєктів) виробила надійні підходи, які мінімізують ризики. Ми гарантуємо якість на кожному етапі роботи. У цій статті розберемо, як реалізувати адресну книгу без компромісів.
Чому адресна книга — критичний компонент мобільного гаманця?
Адресна книга — це не просто UI-список. Вона включає валідацію на рівні криптографії, захищене зберігання та інтеграцію з операціями відправлення. Без неї користувач щоразу вводить адресу вручну, що провокує помилки. Багато гаманців обмежуються простим списком, але це призводить до підтримки лише однієї мережі та відсутності checksum-валідації. Наш підхід — мультимережева книга з обов'язковою перевіркою формату для кожного блокчейну. Це в 5 разів швидше розробки з нуля і в 10 разів надійніше самописної валідації без бібліотек. Завдяки нашому досвіду, ми виконуємо роботу в 3 рази швидше ніж середній розробник.
Як валідувати адреси різних блокчейнів?
Кожен блокчейн має свій формат адреси. Перевірка через регулярний вираз — недостатньо, тому що вона не відловлює бітфліп-помилки. Ми використовуємо спеціалізовані бібліотеки для кожного формату.
Ethereum / EVM-сумісні мережі. Адреса — 42 символи (0x + 40 hex). Але цього мало: потрібна EIP-55 checksum-валідація. Адреса 0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe з правильним регістром — це checksum-адреса. Без перевірки регістру можна прийняти бітфліп-помилку. На мобільних використовуємо Web3j (Android) або web3swift (iOS). Перевірка через регулярний вираз без checksum пропускає до 10% бітфліп-помилок, в той час як EIP-55 валідація знижує ризик до 0.01% — це в 1000 разів надійніше.
Bitcoin. Base58Check для legacy (1...), Bech32 для SegWit (bc1...), Bech32m для Taproot (bc1p...). Бібліотека BitcoinKit для iOS, bitcoinj для Android.
Solana. Base58, 32 байти. Через @solana/web3.js в React Native або Solana.swift.
Приклад EIP-55 валідації через web3swift
import web3swift let address = EthereumAddress(userInput) guard address != nil else { showError("Некоректна адреса") return } | Блокчейн | Префікс | Довжина | Валідація |
|---|---|---|---|
| Ethereum (EVM) | 0x | 42 hex | EIP-55 checksum |
| Bitcoin Legacy | 1,3 | 34 | Base58Check |
| Bitcoin SegWit | bc1 | 42 | Bech32 |
| Bitcoin Taproot | bc1p | 42 | Bech32m |
| Solana | (немає) | 44 base58 | ed25519 |
Чому варто додати підтримку memo-полів?
При проєктуванні моделі даних часто забувають про поле memo. Воно критичне для мереж Ripple, Cosmos, Stellar, TON. Без тегу переказ на біржу може піти не на той акаунт. Ми включаємо memo в модель і перевіряємо його під час відправлення. Гаманці без memo-поля призводять до втрати коштів у 3% випадків при відправленні на біржі з депозитними тегами — наша реалізація повністю усуває цей ризик.
Як захистити дані адресної книги?
Зберігати адреси потрібно локально — Room (Android) або Core Data (iOS). Модель мінімальна:
Модель даних AddressEntry
@Entity(tableName = "address_book") data class AddressEntry( @PrimaryKey(autoGenerate = true) val id: Long = 0, val label: String, val address: String, val network: String, // "ETH", "BTC", "SOL" val memo: String? = null, // для XRP, ATOM, TON val createdAt: Long = System.currentTimeMillis() ) Шифрування сховища: адресна книга — менш чутливі дані, ніж приватні ключі, але SQLCipher для Room або NSFileProtection.complete для Core Data не завадить.
| Спосіб зберігання | Переваги | Недоліки |
|---|---|---|
| Локальне (SQLCipher/Core Data) | Повний контроль, офлайн-доступ, безпека | Немає синхронізації між пристроями |
| Хмарне (CloudKit, Room + Firebase) | Синхронізація, резервне копіювання | Залежність від мережі, питання приватності |
Ми рекомендуємо локальне зберігання з шифруванням, при необхідності — хмарну синхронізацію через власну модель.
UX: введення та вставка адреси
Три способи додати адресу:
- Вручну — з inline-валідацією після втрати фокусу
- Вставка з буфера — автоматично визначати, чи є в clipboard валідна адреса потрібної мережі, і показувати suggestion
- QR-сканер — через MLKit Barcode Scanning (Android) або AVFoundation + Vision (iOS)
Clipboard-моніторинг на iOS вимагає явного дозволу користувача починаючи з iOS 14 (UIPasteboard.general.detectPatterns). На iOS 16+ з'явився UIPasteButton — нативний спосіб без запиту дозволу.
Процес роботи
- Аналіз — визначаємо список підтримуваних мереж, уточнюємо вимоги до UX.
- Проєктування — модель даних, вибір бібліотек, прототип UI.
- Реалізація — інтеграція валідації, QR-сканера, шифрування.
- Тестування — перевірка на реальних адресах, включаючи граничні випадки.
- Деплой — публікація в App Store / Google Play.
Що входить в роботу
- Модель даних з підтримкою кількох мереж та memo-полів
- Валідація адрес (EVM checksum, Bech32, Base58Check)
- QR-сканер для додавання адреси
- Clipboard-детект з підказкою
- Локальне зашифроване сховище
- Пошук та сортування за label/network
- Тестування та виправлення помилок
Терміни та вартість орієнтовно
Базова адресна книга для однієї мережі: від $500, 1 день. Мультимережева з QR, clipboard-детектом та валідацією всіх форматів: від $1200, 2–3 дні. Вартість розраховується індивідуально в залежності від кількості мереж та складності. Ми надаємо гарантію на всі роботи та безкоштовну підтримку протягом місяця після здачі.
Зв'яжіться з нами, щоб обговорити ваш проєкт. Отримайте консультацію з реалізації адресної книги під ключ. Оцінимо проєкт безкоштовно і запропонуємо оптимальне рішення.