HD-кошелёк Bitcoin: иерархические ключи и пути
Библиотека выдаёт отдельный адрес каждому счёту. Если для каждого адреса хранить независимый секрет без общей структуры, восстановление быстро становится неудобным. Иерархические детерминированные ключи позволяют описать семейство ключей с помощью исходного материала и правил вывода. В уроке построим модель ветвей получения и сдачи, сохранив границы доступа.
Мы не создаём seed, мнемоническую фразу или ключи. Все обозначения ниже являются схемой. Учебный результат — понимание, какие данные позволяют подписывать, наблюдать и восстанавливать множество адресов.
Дерево производных ключей
BIP 32 описывает иерархическое получение дочерних ключей. Узел дерева содержит ключевой материал и дополнительные данные, необходимые для дальнейшего вывода. Расширенный приватный ключ позволяет получать секреты соответствующей ветви, а расширенный публичный — наблюдать определённые публичные потомки при подходящем типе вывода.
Важное отличие от обычного открытого ключа: расширенный публичный ключ описывает не только одну проверку подписи. Он может раскрывать последовательность назначений. Поэтому публикация такого значения способна раскрыть историю и будущие адреса библиотеки, хотя сама по себе не даёт общего права расходования.
Структура пути записывается последовательностью индексов. Например, учебная схема может выделить ветвь получения 0 и ветвь сдачи 1 внутри выбранного аккаунта. Это соглашение конкретного профиля кошелька; одна короткая строка пути не является универсальной политикой всех типов адресов.
корень
└─ аккаунт библиотеки
├─ получение: индекс 0, 1, 2, …
└─ сдача: индекс 0, 1, 2, …Номер счёта не обязан совпадать с индексом ключа. Сайт хранит самостоятельную связь invoiceId → выданный адрес → индекс наблюдения, а кошелёк знает правило ветви. Это позволяет менять последовательность заказов без нарушения криптографического дерева.
Обычный и усиленный вывод
В иерархии различают обычный и hardened-вывод. Для обычного публичного потомка возможно вычисление из подходящего расширенного публичного родителя. Для hardened-перехода требуется приватный материал. Эти различия определяют, на каком уровне можно отделить наблюдатель от подписанта.
Нельзя выдать наблюдателю публичный корень и потребовать, чтобы он самостоятельно прошёл любую произвольную hardened-часть пути. При проектировании сначала определяем границу аккаунта и затем экспортируем подходящий публичный материал для разрешённой ветви. Дескриптор фиксирует нужный путь и тип условия более полно, чем один xpub.
Существуют тонкие последствия совместного раскрытия расширенного публичного родителя и определённого приватного дочернего материала при обычном выводе. Поэтому неправильно утверждать, что любой дочерний секрет безопасно публиковать, если основной приватный ключ скрыт. Границы дерева должны оцениваться по спецификации, а секреты никогда не включаются в учебный репозиторий.
Seed и мнемоническая фраза
Исходный материал и способ его представления — разные понятия. Некоторые кошельки предлагают мнемоническую фразу по отдельному стандарту; другие хранят исходные секреты иначе. Bitcoin Core не следует автоматически описывать как кошелёк с обязательной привычной фразой восстановления только потому, что он использует детерминированные структуры.
Резервная инструкция должна соответствовать выбранному инструменту. Если оператор запомнил фразу, которая относится к другому приложению, она не восстановит произвольный кошелёк Core. Если сохранён seed без сведений о путях и типах адресов, секреты могут существовать, но поиск правильной истории останется затруднённым.
Для библиотеки копия включает модель условий, происхождение ключей, ветви и диапазоны выданных адресов. Секретный материал хранится в своей защищённой процедуре. Таблица счетов дополнительно сохраняется как прикладная информация: она не выводится из seed и не содержится в блокчейне.
Получение и сдача
Новый счёт получает следующий допустимый адрес ветви получения. После отправки собственного расхода кошелёк использует адрес ветви сдачи. Такие адреса могут выглядеть одинаково по формату, но их назначение различается для внутреннего учёта.
Допустим, библиотека выдала адреса индексов 0–24, а последний оплаченный счёт находится на индексе 18. При восстановлении нельзя предположить, что следующий адрес обязательно 19: счета 19–24 уже показаны людям и могут получить поздние переводы. Поэтому нужен журнал выдачи, а не только поиск использованных адресов.
Ветвь сдачи тоже должна быть включена в восстановительную модель. Если копия наблюдателя содержит только получение, баланс после собственных расходов может выглядеть исчезнувшим. На самом деле средства находятся в контролируемых выходах другой ветви, которую наблюдатель не ищет.
От дерева к политике
HD-структура описывает происхождение ключей, но не сама по себе все правила расходования. Один и тот же публичный материал можно использовать в разных скриптах. Для корректного адреса нужны тип выхода, путь и, при сложной политике, дополнительные участники или ветви.
Поэтому следующее уточнение — дескриптор. Он соединяет криптографическое происхождение с формой условия. Для библиотеки полезно иметь документ, который говорит не только «этот ключ наш», но и «вот из каких дочерних ключей и каким способом сформированы принимаемые выходы».
При экспорте ограничиваем полномочия и объём наблюдения. Веб-сервису для выдачи адресов аккаунта библиотеки не требуется материал другого аккаунта оператора. Разделение снижает как риск расходования, так и раскрытие посторонней истории.
Ожидаемая сверка
В будущей лаборатории один и тот же профиль и один публичный материал должны приводить к одинаковым публичным назначениям. Если результаты расходятся, сначала проверяем путь, сеть, тип адреса и диапазон. Не объявляем потерю средств только из-за того, что новый интерфейс показал другое семейство адресов.
Два независимых семейства
Если библиотека вводит отдельный аккаунт для пожертвований, он получает собственную наблюдающую политику и журнал назначения. Цена курса не выводится из структуры ключей. Такое разделение позволяет менять учёт и права доступа, не передавая серверу избыточный публичный материал. При восстановлении оба аккаунта перечисляются явно; наличие одного не означает автоматического поиска второго. Происхождение каждого сохраняется рядом с его назначением, чтобы оператор не смешал технически похожие ветви и коммерчески разные поступления.
Спецификация и ограничения описаны в BIP 32. После урока у библиотеки есть схема ветвей, граница публичного экспорта и перечень данных восстановления. Криптографическое дерево помогает повторить назначения, но журнал выданных счетов сохраняется отдельно.