Кошельки и key management

3.7 миллиона Bitcoin потеряны навсегда. Это 150 миллиардов, запертых в блокчейне без возможности доступа. Причина? Люди теряют 256-битные числа. Забытый пароль Gmail восстанавливается за минуту. Забытый seed phrase - приговор без апелляции. Индустрия, обслуживающая триллионы долларов, не может строиться на «запиши 24 слова и не потеряй бумажку». От HD-кошельков, где одно зерно порождает бесконечность ключей, через MPC, где ключ не существует целиком ни в одной точке мира, до account abstraction, где вход по отпечатку пальца заменяет криптографический обряд - эта история о том, как блокчейн учится быть удобным, не жертвуя безопасностью.

• **Ledger** продал 6+ миллионов hardware wallets - люди платят 80-400 за устройство, единственная функция которого - безопасно хранить 256-битное число
• **Safe (Gnosis Safe)** хранит 100B+ в smart contract wallets с multisig - крупнейшие DAO и протоколы не доверяют одному ключу
• **Coinbase** запустил Smart Wallet с passkeys - вход по Face ID, без seed phrase, gas спонсируется через ERC-4337 paymaster

Предварительные знания

• Digital Signatures: ECDSA and EdDSA

HD Wallets: одно зерно - бесконечность ключей

Ранние Bitcoin-кошельки (Bitcoin Core до v0.13) генерировали каждый приватный ключ **независимо**. Файл `wallet.dat` содержал пул из 100 случайных ключей. Создал новый адрес - ключ добавился в файл. Потерял файл - потерял все средства. Восстановил старый backup - и обнаружил, что новые адреса, созданные после backup, **не восстановились**.

**BIP-32** (Hierarchical Deterministic Wallets) решил эту проблему радикально: все ключи выводятся из **одного master seed** через детерминированную функцию. Одно число (256 бит) порождает бесконечное дерево дочерних ключей. Один backup - все адреса восстановлены, включая те, что будут созданы в будущем.

**Derivation path** - «адрес» в дереве ключей. Путь `m/44'/60'/0'/0/0` читается так: - `m` - master key - `44'` - BIP-44 стандарт (hardened) - `60'` - Ethereum (coin type по SLIP-44: Bitcoin = 0, Solana = 501) - `0'` - первый аккаунт - `0` - external chain (адреса для получения) - `0` - первый адрес Апостроф `'` означает **hardened derivation**: дочерний ключ невозможно вычислить из extended public key. Без hardened-уровня утечка одного дочернего приватного ключа + xpub раскрывает **все** ключи в ветке.

**Extended Public Key (xpub)** - позволяет генерировать все **публичные** ключи ветки без доступа к приватным. Это незаменимо для watch-only кошельков: бухгалтер видит все транзакции компании, но не может тратить средства. Однако делиться xpub опасно: кто знает xpub - видит **все** ваши адреса и балансы.

**Hardware wallets** (Ledger, Trezor, GridPlus) хранят master seed в **защищённом чипе** (Secure Element). Приватные ключи никогда не покидают устройство: транзакция подписывается внутри чипа, а наружу выходит только подпись. Даже если компьютер заражён вирусом, seed в безопасности.

**Ledger Recover (2023)** вызвал скандал: Ledger добавил функцию шардирования seed phrase и отправки зашифрованных частей на серверы. Криптосообщество отреагировало жёстко - если seed может покинуть чип, значит Secure Element не так уж secure. Ledger сделал функцию опциональной, но доверие пошатнулось.

BIP-39: мнемонические фразы

Master seed - 256 бит энтропии. В hex это выглядит так: `7f8a3c...d4e1b9` (64 символа). Запомнить невозможно, переписать - легко ошибиться. **BIP-39** решает эту проблему, кодируя энтропию в последовательность **обычных слов** из словаря в 2048 слов.

**Checksum** - встроенная проверка целостности. Если записать одно слово неправильно, кошелёк обнаружит ошибку при восстановлении. Но checksum ловит не все ошибки - он всего 4-8 бит. Два случайных слова совпадут по checksum с вероятностью ~1/16 для 12-словной фразы.

**Passphrase (25-е слово)** - необязательный пароль, который добавляется при деривации seed из мнемоники: `seed = PBKDF2(mnemonic, "mnemonic" + passphrase, 2048, 64)` Разные passphrase порождают **разные кошельки** из одной мнемоники. Это открывает возможность «plausible deniability»: основные средства на passphrase-кошельке, а пустой кошелёк (без passphrase) - декой при физическом принуждении.

**Главные ошибки хранения seed phrase:** 1. **Фотография** - синхронизируется в iCloud/Google Photos. Взлом аккаунта = потеря средств 2. **Заметки / password manager** - цифровое хранение уязвимо к малвари и бэкапам в облаке 3. **Бумага** - горит, мокнет, выцветает. Один пожар - и всё потеряно 4. **Разделение на части** (6+6 слов в разных местах) - снижает безопасность! 6 слов = 66 бит, brute-force реален **Решение:** металлические backup (Cryptosteel, Billfodl) - гравировка или сборка из букв на стальной пластине. Выдерживает огонь до 1500°C, воду и коррозию.

**BIP-39 wordlist** содержит 2048 слов. Каждое слово уникально определяется первыми **4 буквами** (например, `aban` → `abandon`). Это не случайность - стандарт гарантирует отсутствие пар с одинаковыми 4-буквенными префиксами. Существуют wordlist на разных языках (English, Japanese, Spanish и др.), но на практике почти все кошельки используют **английский** - другие языки вносят путаницу с Unicode-нормализацией.

MPC Wallets: ключ, которого нет ни у кого

Seed phrase решает проблему backup, но создаёт новую: **single point of failure**. Кто знает 12/24 слова - владеет всем. Для институциональных инвесторов, хранящих миллиарды, это неприемлемый риск. Нужно, чтобы **ни один человек** не имел полного ключа - ни при генерации, ни при подписании.

**MPC (Multi-Party Computation)** - криптографический протокол, где несколько участников **совместно вычисляют** результат функции, **не раскрывая** свои входные данные друг другу. В контексте кошельков это **TSS** (Threshold Signature Scheme): N участников держат «осколки» (shares) ключа, и для подписи нужны любые T из N - при этом полный ключ **никогда не собирается** в одном месте.

**Ключевые свойства MPC-TSS:** 1. **Distributed Key Generation (DKG)** - ключ генерируется распределённо. Каждый участник получает share, но полный ключ не создаётся даже на мгновение 2. **Threshold signing** - для подписи достаточно T из N shares. Протокол GG18/GG20 (Gennaro & Goldfeder) - самый распространённый для ECDSA 3. **Key resharing** - shares можно «перенарезать» без смены публичного ключа. Увольняется сотрудник? Его share становится бесполезной после resharing 4. **Proactive security** - периодический resharing защищает от атакующего, который медленно собирает shares

**Кто использует MPC-кошельки:** - **Fireblocks** - институциональный кастодиан, 4+ трлн в транзакциях. MPC-CMP протокол, 8 подписей в секунду - **ZenGo** - потребительский кошелёк без seed phrase. 2-of-2 MPC: одна share на телефоне, вторая на серверах ZenGo. Восстановление через 3D Face Map - **Coinbase WaaS** (Wallet-as-a-Service) - API для встраивания MPC-кошельков в любое приложение - **Банки и фонды** - Fidelity, Galaxy Digital, Revolut используют MPC для хранения криптоактивов

**Почему не просто Shamir's Secret Sharing?** SSS разделяет секрет на shares и восстанавливает при сборе threshold. Но для подписания SSS **пересобирает** полный ключ в одном месте - single point of failure возвращается! MPC-TSS подписывает **без пересборки**: каждый участник вычисляет «частичную подпись», которые математически комбинируются в одну валидную подпись.

**MPC - не панацея.** В июне 2023 года хакеры украли **100M** у Atomic Wallet, несмотря на MPC-архитектуру. Проблема оказалась не в криптографии, а в инфраструктуре: уязвимость в процессе key generation позволила перехватить shares. MPC защищает хранение и подписание, но не защищает от багов в реализации протокола.

Account Abstraction: кошелёк как смарт-контракт

В Ethereum существуют два типа аккаунтов: **EOA** (Externally Owned Account) - управляется приватным ключом, и **Contract Account** - управляется кодом смарт-контракта. EOA - единственный тип, который может инициировать транзакцию. И у него серьёзные ограничения:

**Account Abstraction** - идея о том, что **кошелёк = смарт-контракт** с произвольной логикой валидации. Вместо жёсткого `ecrecover(signature) == owner` контракт сам решает, какая подпись валидна. Это открывает возможности, невозможные с EOA.

**Social Recovery** - одна из главных возможностей smart contract wallets. Вы назначаете **guardians** (доверенных лиц): друзья, семья, hardware wallet, другой ваш кошелёк. Если потеряли ключ - guardians голосуют за смену owner. **Argent Wallet** реализовал это первым: 3-of-5 guardians + 48-часовой timelock (защита от компрометации guardians).

**Session Keys** - ещё одна революционная возможность. Вместо подтверждения каждой транзакции в MetaMask, вы выдаёте dApp временный ключ с ограничениями: - Срок: 1 час - Лимит: до 0.1 ETH за транзакцию - Контракты: только Uniswap Router DApp подписывает транзакции session key без вашего участия. Это UX уровня Web2 с безопасностью Web3.

**Passkeys (WebAuthn)** - биометрическая аутентификация вместо seed phrase. Чип в iPhone/Android создаёт пару ключей (P-256), защищённую Face ID / отпечатком. Smart contract wallet верифицирует подпись P-256 on-chain. Coinbase Smart Wallet и Safe уже поддерживают passkeys. Для пользователя это выглядит так: приложил палец → транзакция подписана.

ERC-4337: Account Abstraction без изменения протокола

Идея account abstraction обсуждалась с 2016 года (EIP-86), но требовала **изменения протокола Ethereum** (hard fork). Это означало годы обсуждений и риск раскола сообщества. **ERC-4337** (Виталик Бутерин и др., 2023) нашёл обходной путь: реализовать AA **полностью на уровне смарт-контрактов**, без изменения консенсуса.

**Paymaster** - контракт, который **платит за gas** вместо пользователя. Это убирает главный барьер входа: новому пользователю не нужно покупать ETH. Два основных паттерна: 1. **Sponsoring Paymaster** - dApp оплачивает gas своих пользователей. GameFi-проект спонсирует первые 10 транзакций бесплатно 2. **ERC-20 Paymaster** - пользователь платит gas в USDC/DAI. Paymaster конвертирует в ETH через DEX и перечисляет bundler'у

**Bundler** - узел, который собирает UserOperations из alt mempool в пакет (bundle) и отправляет его как **обычную транзакцию** в EntryPoint. Bundler платит gas из своего ETH, а EntryPoint возвращает затраты (из кошелька пользователя или paymaster). Ведущие bundler-провайдеры: **Pimlico**, **Stackup**, **Alchemy**, **Biconomy**.

**Реальные реализации:** - **Safe{Core}** (бывший Gnosis Safe) - 100B+ активов под управлением. Модульная архитектура с ERC-4337 модулем - **Biconomy** - SDK для интеграции AA в dApps за 15 минут. Paymaster, bundler и smart account из коробки - **ZeroDev** - kernel-архитектура: минимальный base wallet + плагины (session keys, recovery, automation) - **Pimlico** - инфраструктура: bundler, paymaster, permissionless.js (TypeScript SDK)

**Будущее: Native Account Abstraction (RIP-7560).** ERC-4337 работает, но имеет overhead: EntryPoint - это дополнительный контракт, bundler - дополнительная инфраструктура. RIP-7560 предлагает встроить AA **в протокол Ethereum**: валидаторы сами обрабатывают UserOperations, убирая прослойку. Это потребует hard fork, но после успеха ERC-4337 сообщество готово. На L2 (zkSync Era, StarkNet) native AA уже работает - каждый аккаунт по умолчанию smart contract.

**Эволюция в цифрах (2023→2025):** - Активных ERC-4337 кошельков: 500K → 12M+ - UserOperations в месяц: 200K → 30M+ - Сети с поддержкой: 3 → 20+ (включая L2: Base, Optimism, Arbitrum, Polygon) - Средняя экономия gas с батчингом: 30-50% по сравнению с отдельными EOA-транзакциями

Итоги

• **HD Wallets (BIP-32)** - одно зерно (master seed) порождает бесконечное дерево ключей через детерминированную деривацию. Один backup = все адреса, включая будущие. Derivation path определяет, какой ключ для какой сети
• **BIP-39** - кодирует 128/256 бит энтропии в 12/24 слова из словаря 2048 слов. Passphrase создаёт скрытые кошельки. Но физическое хранение - нерешённая проблема: бумага горит, фотографии утекают, цифровые копии взламываются
• **MPC-TSS** - ключ разделён на shares, которые никогда не собираются вместе. Подписание через распределённый протокол. Key resharing позволяет ротировать участников без смены адреса. Для институционалов это стандарт
• **Account Abstraction (ERC-4337)** - кошелёк = смарт-контракт с произвольной логикой. Social recovery, session keys, batching, gas abstraction через paymaster. Те самые 150 миллиардов потерянных Bitcoin? С AA их можно было бы восстановить через guardians - друзей и семью, назначенных заранее
• **Архитектура ERC-4337**: UserOperation → Alt Mempool → Bundler → EntryPoint → Smart Wallet + Paymaster. Всё работает поверх существующего Ethereum без hard fork. На L2 (zkSync, StarkNet) native AA уже встроен в протокол

Связанные темы

Кошельки и key management стоят на пересечении криптографии, архитектуры блокчейна и user experience:

• Цифровые подписи (ECDSA, EdDSA) — Фундамент кошельков - каждый тип кошелька в конечном счёте создаёт подпись, которую верифицирует сеть. HD wallets, MPC, AA - это разные способы управления ключами подписи
• Threshold Cryptography — MPC-TSS - это конкретная реализация пороговых схем. Threshold signatures (t-of-n) позволяют распределить доверие без single point of failure
• Ethereum Roadmap — Account abstraction - часть дорожной карты Ethereum (The Splurge). RIP-7560 (native AA) планируется для будущих hard fork, а ERC-4337 уже работает
• Ethereum Accounts — EOA vs Contract Account - базовое разделение, которое account abstraction стирает. EIP-7702 позволит EOA временно делегировать логику смарт-контракту

Вопросы для размышления

• Если passkeys (Face ID / отпечаток) заменят seed phrase, кто хранит приватный ключ? Apple/Google владеют Secure Enclave вашего устройства. Чем это отличается от банка, который хранит ваш пароль? Не возвращаемся ли мы к централизации?
• MPC-кошелёк ZenGo хранит одну share на серверах компании. Если ZenGo прекратит работу - пользователи потеряют доступ? Как решить эту проблему, сохранив удобство для нетехнических пользователей?
• Account abstraction позволяет кошельку менять алгоритм подписи. Если завтра появится квантовый компьютер, взламывающий ECDSA, - пользователи AA смогут перейти на постквантовую подпись без перевода средств. Владельцы EOA потеряют всё. Должен ли Ethereum принудительно мигрировать всех на AA ради безопасности?

Связанные уроки

• crypto-18-key-management