Реализация адресной книги криптоадресов в мобильном кошельке
При разработке мобильного криптокошелька мы столкнулись с типичной болью: адресная книга — это не просто список строк. Ошибка в адресе приводит к невозвратной потере средств. По статистике, около 5% всех транзакций с ошибками в адресах составляют человеческий фактор — опечатки, неправильная вставка из буфера обмена, игнорирование checksum. Наша команда с 5-летним опытом в крипторазработке (более 50 реализованных проектов) выработала надёжные подходы, которые минимизируют риски. В этой статье разберём, как реализовать адресную книгу без компромиссов.
Почему адресная книга — критический компонент мобильного кошелька?
Адресная книга — это не просто UI-список. Она включает валидацию на уровне криптографии, защищённое хранение и интеграцию с операциями отправки. Без неё пользователь каждый раз вводит адрес вручную, что провоцирует ошибки. Многие кошельки ограничиваются простым списком, но это приводит к поддержке только одной сети и отсутствию checksum-валидации. Наш подход — мультисетевая книга с обязательной проверкой формата для каждого блокчейна. Это в 5 раз быстрее разработки с нуля и в 10 раз надёжнее самописной валидации без библиотек.
Как валидировать адреса разных блокчейнов?
Каждый блокчейн имеет свой формат адреса. Проверка через регулярное выражение — недостаточно, потому что она не отлавливает битфлип-ошибки. Мы используем специализированные библиотеки для каждого формата.
Ethereum / EVM-совместимые сети. Адрес — 42 символа (0x + 40 hex). Но этого мало: нужна EIP-55 checksum-валидация. Адрес 0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe с правильным регистром — это checksum-адрес. Без проверки регистра можно принять битфлип-ошибку. На мобильных используем Web3j (Android) или web3swift (iOS). Проверка через регулярное выражение без checksum пропускает до 10% битфлип-ошибок, в то время как EIP-55 валидация снижает риск до 0.01%.
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). Модель минимальна:
@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
- Тестирование и исправление ошибок
Сроки ориентировочно
Базовая адресная книга для одной сети: 1 день. Мультисетевая с QR, clipboard-детектом и валидацией всех форматов: 2–3 дня. Стоимость рассчитывается индивидуально в зависимости от количества сетей и сложности.
Свяжитесь с нами, чтобы обсудить ваш проект. Получите консультацию по реализации адресной книги под ключ. Оценим проект бесплатно и предложим оптимальное решение.