---
title: "Иерархический детерминированный (HD) кошелек"
description: "Узнайте, как HD-кошелек выводит дерево ключей из одной исходной последовательности, чем усиленное выведение отличается от обычного и что необходимо сохранить в полной, проверяемой резервной копии кошелька."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Иерархический детерминированный (HD) кошелек
> Материал предназначен только для образовательных целей и не является инвестиционной рекомендацией. Инвестирование может привести к убыткам.
## Краткий ответ
Иерархический детерминированный (HD) кошелек создает воспроизводимое дерево криптографических пар ключей из одной корневой исходной последовательности. BIP-32 определяет механизм дерева ключей: каждый узел является расширенным ключом, содержащим ключ и цепной код размером `32-byte`, а дочерний элемент выбирается по индексу. Одинаковые корневые данные, правила выведения и путь воспроизводят одинаковые дочерние ключи.
«Детерминированность» упрощает резервное копирование, но не делает все кошельки взаимозаменяемыми. Мнемоническая фраза — один из способов закодировать энтропию и получить исходную последовательность; путь выведения выбирает узел, а правило адреса или скрипта преобразует его открытый ключ в объект, распознаваемый сетью. Если отличаются парольная фраза, путь, сеть, тип скрипта или правила поиска аккаунтов, восстановление только по словам может показать пустой кошелек.
«Иерархичность» означает, что полномочия можно разделить между поддеревьями. Расширенный открытый ключ уровня аккаунта позволяет кошельку только для наблюдения выводить обычные дочерние открытые ключи, не владея ключами для расходования средств. Расширенный закрытый ключ способен вывести соответствующее закрытое поддерево, поэтому его нужно защищать как набор закрытых ключей, а не как один адрес.
HD-кошелек — это модель управления ключами, а не объект кошелька в блокчейне. Блокчейн не хранит мнемонику, исходную последовательность, путь, метки или резервную копию. Это внесетевые данные, которые хранят программа кошелька и пользователь.
## Как это работает
### 1. От энтропии к корню
BIP-39 часто применяется до BIP-32, однако это разные стандарты. BIP-39 кодирует `128-256 bits` энтропии вместе с контрольной суммой в `12-24 words`, а затем применяет PBKDF2-HMAC-SHA512 с `2048` итерациями к нормализованной мнемонике и необязательной парольной фразе, получая `512-bit` исходную последовательность. Любая парольная фраза создает допустимую, но другую исходную последовательность, поэтому отсутствие или опечатка в ней не всегда выявляется сообщением «неверный пароль».
BIP-32 применяет HMAC-SHA512 с ключом `Bitcoin seed`, чтобы преобразовать байты исходной последовательности в главный закрытый ключ и главный цепной код. Этот корневой расширенный закрытый ключ служит источником дерева BIP-32. Не каждый детерминированный кошелек использует BIP-39 или BIP-32, поэтому при восстановлении нужно определить фактическую схему, а не делать вывод только по наличию слов восстановления.
### 2. Расширенные ключи и выведение дочерних ключей
Расширенный закрытый ключ BIP-32 объединяет закрытый ключ с цепным кодом; соответствующий обезличенный расширенный открытый ключ объединяет подходящий открытый ключ с тем же цепным кодом. При обычном выведении дочернего ключа используются открытый ключ родителя, цепной код и индекс дочернего элемента, поэтому расширенный открытый ключ может выводить обычные дочерние открытые ключи. Дочерние закрытые ключи он вывести не может.
Усиленные дочерние ключи используют индексы от `2^31` до `2^32 - 1` и включают материал закрытого ключа родителя. Их нельзя вывести из расширенного открытого ключа родителя. В путях они обычно помечаются апострофом, например `m/84'/0'/0'`. Усиление ограничивает последствия конкретного сбоя BIP-32: расширенный открытый ключ родителя вместе с соответствующим неусиленным дочерним закрытым ключом позволяет раскрыть расширенный закрытый ключ родителя.
### 3. Пути придают дереву смысл
BIP-44 определяет `m / purpose' / coin_type' / account' / change / address_index`. Первые `3` уровня усилены; `change` и `address_index` являются обычными, чтобы открытые ключи аккаунта могли создавать адреса получения и сдачи. По соглашению ветвь `0` является внешней, а ветвь `1` — внутренней ветвью сдачи. Поиск BIP-44 сканирует историю транзакций и использует предел пропуска в `20` последовательных неиспользованных внешних адресов.
Путь — это метаданные, а не секрет или универсальная гарантия. BIP-84 назначает назначение `84'` нативным SegWit-аккаунтам P2WPKH, тогда как другие назначения или схемы конкретного кошелька создают иные поддеревья. Тип монеты — это соглашение о пространстве имен, а не правило, обеспечиваемое блокчейном.
### 4. Ключи — не весь кошелек
Открытому ключу все еще нужны правила сети и адреса или скрипта. В Bitcoin один ключ может участвовать в разных выходных скриптах, а мультиподписному кошельку также необходимы порог подписей, ключи соучастников, порядок ключей и происхождение путей выведения. Дескрипторы выходных скриптов BIP-380 связывают ключи и их происхождение с явными выражениями скриптов и могут включать контрольную сумму. Поэтому резервной копии только исходной последовательности может быть недостаточно, чтобы воссоздать то, что исходный кошелек отслеживал или мог тратить.
Метки кошелька, контакты, примечания к транзакциям, импортированные ключи, названия аккаунтов и некоторые настройки восстановления контрактов или смарт-аккаунтов обычно не выводятся детерминированно. Их необходимо экспортировать или документировать отдельно.
### 5. Резервное копирование и восстановление необходимо проверять
Запишите реализацию кошелька, формат мнемоники или исходной последовательности, наличие парольной фразы, главный отпечаток, нужные пути, сети, индексы аккаунтов и дескрипторы Bitcoin либо эквивалентные данные политики. По возможности храните корневые секреты офлайн и отдельно от общедоступных метаданных восстановления. `xpub` сам по себе не может тратить средства, но способен раскрывать балансы, связи между адресами и будущие обычные дочерние ключи.
Проверьте восстановление в доверенной среде, прежде чем полагаться на резервную копию. Сначала сопоставьте известные адреса или дескрипторы, не перемещая средства; затем проверьте ветви получения и сдачи, последующие аккаунты, историю транзакций и подписание небольшой контролируемой транзакции. Никогда не вводите мнемонику, парольную фразу или `xprv` на недоверенном сайте или в чате поддержки.
## Пример
Рассмотрим нативный SegWit-аккаунт Bitcoin по пути `m/84'/0'/0'`. Назначение `84'` выбирает соглашение BIP-84, `0'` — пространство имен типа монеты Bitcoin, а последний `0'` — первый аккаунт. Система только для наблюдения может получить расширенный открытый ключ аккаунта и вывести обычные ветви, не получая закрытый ключ аккаунта.
Первый внешний ключ получения находится по пути `m/84'/0'/0'/0/0`, следующий — по `m/84'/0'/0'/0/1`. Первый внутренний ключ сдачи находится по `m/84'/0'/0'/1/0`. Все они происходят от одного аккаунта, но ветвь и индекс выбирают разные ключи. Повторное использование исходной последовательности с `m/44'/0'/0'/0/0` выбирает другое поддерево и другое соглашение о выходе; пустой результат не доказывает, что исходная последовательность неверна.
Для полной записи восстановления Bitcoin храните резервную копию корневого секрета отдельно от дескриптора или эквивалентных метаданных, указывающих отпечаток, путь, расширенный открытый ключ, тип скрипта и контрольную сумму. Проверьте несколько ранее использованных адресов в обеих ветвях. Нахождение только первого адреса получения подтверждает правильность одного листа, но не доказывает восстановление каждого аккаунта, выхода сдачи или политики кошелька.
## Риски
- **Концентрация в одном корне:** компрометация корневой исходной последовательности или расширенного закрытого ключа достаточно высокого уровня может раскрыть всех дочерних участников в его области.
- **Утрата резервной копии:** потеря единственной резервной копии исходной последовательности или отдельная потеря незадокументированной парольной фразы BIP-39 может сделать все выведенные ключи невосстановимыми.
- **Ложная уверенность в парольной фразе:** неверная парольная фраза BIP-39 создает другой допустимый кошелек, что может выглядеть как успешное, но пустое восстановление.
- **Несовпадение пути или скрипта:** правильная исходная последовательность с неверным назначением, аккаунтом, ветвью, сетью или типом выхода создает допустимые, но несвязанные адреса.
- **Неполная резервная копия политики:** одной исходной последовательности и пути может быть недостаточно для восстановления условий расходования мультиподписного кошелька, дескриптора, смарт-аккаунта или специфической политики кошелька.
- **Утечка приватности расширенного открытого ключа:** `xpub` может раскрыть кластер адресов и позволить непрерывно отслеживать обычные дочерние ключи.
- **Компрометация родителя BIP-32:** родительский `xpub` вместе с утекшим соответствующим неусиленным дочерним закрытым ключом может раскрыть закрытое поддерево родителя.
- **Недоверенные средства восстановления:** сайты, расширения, поддельные устройства, инструменты буфера обмена или демонстрация экрана могут захватить весь корневой секрет.
- **Непроверенные носители:** бумага, металл, зашифрованные файлы или аппаратные резервные копии могут подвести из-за ошибки записи, коррозии, забытого пароля или неподдерживаемого формата.
- **Неполный перенос:** перемещение видимых монет при сохранении токенов, выходов сдачи, ролей контрактов, разрешений или последующих аккаунтов под старым корнем оставляет риск компрометации.
## Распространенные заблуждения
### Содержит ли одна резервная фраза все сведения о кошельке?
Нет. Она может воспроизвести материал корневого ключа, но необязательно парольную фразу, соглашение о выведении, сеть, скрипты, мультиподписную политику, метки, импортированные ключи или историю поиска аккаунтов. Сохраняйте метаданные, необходимые фактически используемому кошельку.
### Безопасно ли публиковать `xpub`, поскольку он не может тратить средства?
Нет. Обычно он не может подписывать, но способен раскрыть прошлые и будущие обычные дочерние адреса и их объединенную историю. В описанном выше сбое BIP-32 его сочетание с соответствующим неусиленным дочерним закрытым ключом также может скомпрометировать родительское поддерево.
### Создают ли новые адреса независимые резервные копии?
Нет. Новые адреса сокращают повторное использование и улучшают конфиденциальность, однако детерминированные дочерние ключи по-прежнему контролируются одним предком. Компрометация корня затрагивает поддерево, даже если каждый платеж использовал новый адрес.
### Доказывает ли восстановление одного знакомого адреса полноту кошелька?
Нет. Оно подтверждает одну комбинацию корневого материала, пути и способа построения адреса. Восстановление все равно должно охватить ветви получения и сдачи, все использованные аккаунты, скрипты или политики и соответствующие сети.
## Связанные темы
- [Путь выведения кошелька](/ru/crypto/derivation-path/)
- [Сид-фраза](/ru/crypto/seed-phrase/)
- [Открытые и закрытые ключи](/ru/crypto/public-private-key/)
- [Аппаратный кошелек](/ru/crypto/hardware-wallet/)
- [Холодный кошелек](/ru/crypto/cold-wallet/)
## Источники
- [BIP 32: Иерархические детерминированные кошельки](https://bips.dev/32/) - Bitcoin Improvement Proposals (дата обращения: 2026-08-20)
- [BIP 39: Мнемонический код для создания детерминированных ключей](https://bips.dev/39/) - Bitcoin Improvement Proposals (дата обращения: 2026-08-20)
- [BIP 44: Многоаккаунтная иерархия детерминированных кошельков](https://bips.dev/44/) - Bitcoin Improvement Proposals (дата обращения: 2026-08-20)
- [BIP 84: Схема выведения для аккаунтов P2WPKH](https://bips.dev/84/) - Bitcoin Improvement Proposals (дата обращения: 2026-08-20)
- [BIP 380: Общие правила дескрипторов выходных скриптов](https://bips.dev/380/) - Bitcoin Improvement Proposals (дата обращения: 2026-08-20)
Source: https://wiki.fcontext.com/ru/crypto/hd-wallet/index.mdx