Разработка некастодиального криптокошелька.Часть 2: Архитектура и Технологический Стек

Техническая основа некастодиального кошелька определяет его безопасность, пользовательский опыт и будущий потенциал. Каждое архитектурное решение представляет собой компромисс между этими тремя столпами, и неверный выбор на раннем этапе может иметь далеко идущие последствия для рыночного позиционирования и возможностей монетизации.

В основе любого некастодиального кошелька лежит принцип суверенитета пользователя. В отличие от кастодиальных сервисов, таких как централизованные биржи, где третья сторона контролирует приватные ключи и, следовательно, активы пользователя , некастодиальный кошелек предоставляет пользователю полный и эксклюзивный контроль. Это устраняет риск контрагента — например, потерю средств в результате взлома биржи — но одновременно возлагает на пользователя всю полноту ответственности за безопасное хранение своих ключей.

Важно понимать, что кошелек не «хранит» криптовалюту.

Он хранит криптографические ключи, которые предоставляют доступ к активам, записанным в блокчейне. Современные кошельки используют стандарт BIP39 для создания удобной для пользователя резервной копии — seed-фразы. Этот процесс является основой безопасности и восстанавливаемости кошелька и состоит из нескольких шагов :

1. Генерация энтропии: Создание криптографически безопасной случайной последовательности битов.

2. Создание контрольной суммы: Для проверки ошибок к энтропии добавляется ее хэш.

3. Сопоставление со списком слов: Полученная строка делится на группы, каждая из которых соответствует слову из стандартизированного списка, в результате чего получается фраза из 12 или 24 слов.

4. Генерация Seed: Мнемоническая фраза преобразуется в мастер-ключ, из которого детерминированно генерируются все последующие ключи в кошельке с помощью стандартов BIP32 и BIP44.

Основная функция кошелька — позволять пользователю взаимодействовать со своими активами. Этот процесс включает создание, подписание и трансляцию транзакций в блокчейн. Используя приватный ключ пользователя, кошелек создает цифровую подпись для данных транзакции, которая доказывает владение средствами, не раскрывая сам ключ.

Кошелек взаимодействует с сетью через узлы, используя протокол удаленного вызова процедур (RPC). Через RPC-ноды кошелек получает данные о балансах и истории транзакций, а также транслирует новые подписанные транзакции в сеть. Перед разработчиками стоит критический выбор: запускать и поддерживать собственные ноды или использовать сторонние сервисы, такие как Alchemy или Infura. Собственные ноды обеспечивают максимальный контроль, но их поддержка требует значительных затрат. Сторонние провайдеры предлагают надежность и масштабируемость «из коробки», но создают зависимость от третьей стороны.

Это стратегическое решение, определяющее целевую аудиторию и модель безопасности.

• Мобильные кошельки: Нативная разработка (Swift/Kotlin) обеспечивает максимальную производительность и безопасность, используя аппаратные модули, такие как Secure Enclave. Кроссплатформенные решения (React Native) ускоряют и удешевляют разработку, но могут уступать в безопасности.

• Браузерные расширения: Самый распространенный форм-фактор для взаимодействия с dApps (пионер — MetaMask). Они удобны, но являются основной целью для злоумышленников из-за фишинга и вредоносных клонов. Широкие разрешения, требуемые кошельками, создают значительный риск.

• TMA: Telegram Mini Apps. Сильно напоминают браузерные расширения - скороть создания и отладки такая же.

• Десктопные кошельки: Часто создаются на фреймворке Electron, который имеет большую поверхность для атаки и требует усиленных мер безопасности.

Выбор платформы — это стратегический компромисс. Нативная мобильная разработка предлагает наилучшую безопасность, а браузерные расширения обеспечивают наибольшее удобство для dApps, но являются наиболее уязвимыми.