Перейти к содержанию
Financial Context Wiki

Пути деривации кошелька: стандарты, обнаружение и восстановление

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

Обновлено

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Краткий ответ

Путь деривации кошелька — это упорядоченная последовательность дочерних индексов, которая указывает детерминированному алгоритму деривации ключей, какой узел выбрать в дереве ключей. В обычной нотации BIP-32 путь m/84'/0'/0'/0/7 начинается с главного приватного узла m и проходит через пять дочерних узлов. Апостроф обозначает усиленную деривацию дочернего узла BIP-32. Путь — это маршрутные метаданные: он не является приватным ключом, не шифрует seed, сам по себе не определяет баланс в блокчейне и ничего не восстанавливает без правильного корневого материала и алгоритма деривации.

Для кошельков в стиле BIP-44 используется шаблон m / purpose' / coin_type' / account' / change / address_index. Уровни имеют согласованные значения, а не произвольные метки. purpose выбирает соглашение кошелька, coin_type разделяет зарегистрированные пространства имён активов, account — логические аккаунты, change обычно отличает внешние адреса получения (0) от внутренних адресов сдачи (1), а address_index выбирает конечный ключ. BIP-44 использует усиленную деривацию на первых трёх уровнях и обычную на последних двух, чтобы расширенный публичный ключ аккаунта мог выводить адреса получения и сдачи без приватных ключей.

Один и тот же мнемонический код может привести к множеству допустимых, но не связанных между собой наборов адресов. Для Bitcoin распространённые пути с одним ключом включают m/44'/0'/account'/change/index для P2PKH, m/49'/0'/account'/change/index для P2WPKH в P2SH, m/84'/0'/account'/change/index для родного SegWit P2WPKH и m/86'/0'/account'/change/index для одноключевого Taproot P2TR. Кошелёк также должен знать структуру вывода или скрипта; один только путь не является полной политикой кошелька Bitcoin.

Другие экосистемы повторно используют части этой нотации без гарантии идентичной семантики. Эфир зарегистрирован как тип монеты BIP-44 с кодом 60, а m/44'/60'/0'/0/index является общепринятой конвенцией для внешне управляемых аккаунтов, но реализации кошельков использовали несколько вариантов размещения аккаунтов. Один и тот же ключ EVM может создать один и тот же адрес аккаунта в нескольких сетях EVM, хотя балансы и история транзакций зависят от цепочки. Валидаторские BLS-ключи Ethereum используют ERC-2333 и ERC-2334 вместо BIP-32; их путь m/12381/3600/account/use не содержит апострофов и не совместим с деревом BIP-32. Следовательно, восстановление требует точной реализации, кривой, начального значения или пароля, конвенции пути, сети и построения адреса, а не строки, которая выглядит правдоподобно.

Как определить и проверить путь деривации

1. Определить исходные данные и алгоритм деривации

Инвентаризируйте мнемонический формат, список слов, дополнительную фразу-пароль, исходный ключ или расширенный ключ, а также программную или аппаратную реализацию, которая создала кошелек. BIP-39 преобразует 128 в 256 бит энтропии в мнемонику и выводит 512-bit исходный ключ из этой мнемоники и точной фразы-пароля; каждая фраза-пароль создает синтаксически правильный, но другой исходный ключ. BIP-32 затем выводит расширенные ключи secp256k1 из исходного ключа. Другие семейства кошельков могут использовать разные мнемонические схемы, кривые, функции получения ключей или правила главного ключа, поэтому совпадение слов не доказывает совпадение корневого ключа.

2. Определить стандарт, сеть и назначение ключа

Определите, является ли цель платежным ключом Bitcoin, внешне управляемым аккаунтом EVM, ключом валидатора, мультиподписанным подписантом, администратором контракта или другой властью. Зафиксируйте цепочку и сеть, применимый стандарт и версию, кривую ключа, тип вывода или адреса, а также приложение кошелька. Регистрация типа монеты SLIP-0044 выделяет пространство имён; это не доказывает, что каждый кошелек для этого актива следует стандарту BIP-44, не поддерживает проект и не предотвращает использование того же ключа в другой цепочке.

3. Точно разобрать каждый компонент пути

Считайте / границей между родительским и дочерним узлами и сохраняйте каждый индекс, глубину и отметку усиленной деривации. В BIP-32 обычные дочерние ключи используют индексы от 0 до 2^31 - 1, а усиленные — от 2^31 до 2^32 - 1; последние обычно обозначают через ', h или H. Поэтому 7' кодирует дочерний номер 2^31 + 7, а не обычный номер 7. Уточните, как интерфейс импорта обозначает корень, принимает ли полный путь или относительный суффикс и не находится ли экспортированный расширенный ключ уже ниже части этого пути.

4. Связать путь с семантикой адреса или выхода

Для кошельков семейства BIP-44 Bitcoin подтвердите purpose, coin_type, account, change и address_index, затем отдельно подтвердите предполагаемый тип скрипта и сеть. BIP-49, BIP-84 и BIP-86 намеренно используют разные значения назначения, чтобы несовместимые типы выходов не появлялись незаметно в одном аккаунте. Для кошельков с мультиподписью или дескрипторами сохраняйте каждое происхождение ключа, мастер-отпечаток, суффикс деривации, порог, порядок ключей, конструкцию скрипта и контрольную сумму; один путь не может восстановить политику полностью.

5. Воспроизвести обнаружение аккаунтов и адресов

Не делайте вывод о потере средств по одному пустому стандартному аккаунту. Поиск BIP-44 проверяет аккаунты по порядку и сканирует внешнюю ветвь, останавливаясь после 20 последовательных неиспользованных адресов. Стандартное сканирование может не найти кошельки, которые создавали адреса за этим разрывом, необычно использовали внутренние ветви, пропускали аккаунты или применяли собственную структуру. Ищите только с доверенными данными watch-only или офлайн-деривацией, задавайте явные границы, документируйте каждую ветвь и не загружайте мнемоническую фразу или расширенный приватный ключ на сайт.

6. Проверить идентификаторы кошелька до оценки баланса

Сравните мастер-отпечаток, расширенный публичный ключ аккаунта, если он применим, полный путь происхождения и несколько ранее записанных адресов получения и сдачи. Для Bitcoin выведите ожидаемые скрипты выходов или дескриптор и запросите историю транзакций в правильной сети, включая уже потраченные выходы. Для сетей с моделью аккаунтов проверьте точные chainId, адрес, токен-контракты и историю активности. Пустой баланс — слабое доказательство: адрес может быть неверным, сеть или индекс могут отличаться, а активы могли уже переместиться.

7. Восстановить или перенести средства в контролируемом процессе

Используйте проверенное совместимое ПО в доверенной среде. До раскрытия подписывающих данных предпочтительно импортировать watch-only-дескриптор или публичный ключ аккаунта для поиска. Проверьте подписание и восстановление на изолированном аккаунте или небольшой транзакции, затем сверьте полученные адреса, историю в блокчейне, принадлежность выходов, комиссии и конечное состояние. Если секреты вводились в недоверенный инструмент, считайте их скомпрометированными и перенесите на новый корневой ключ все активы, роли контрактов, разрешения, обязанности валидатора и полномочия восстановления, не продолжая использовать восстановленный кошелёк.

Расчётные примеры

Разбор усиленного пути Bitcoin

Рассмотрим m/84'/0'/2'/1/17. Поля означают назначение native SegWit 84', тип монеты Bitcoin 0', аккаунт 2', внутреннюю ветвь или ветвь сдачи 1 и индекс адреса 17. Поскольку усиленные индексы BIP-32 добавляют 2^31 = 2,147,483,648, их сериализованные номера равны 84' = 2,147,483,732, 0' = 2,147,483,648 и 2' = 2,147,483,650. Последние два остаются обычными индексами 1 и 17; пропущенный апостроф выбирает другое поддерево, а не равнозначную запись.

Разрыв поиска, скрывающий использованный адрес

Предположим, во внешней ветви использовались адреса с индексами 0 и 5, после чего кошелёк проверил индексы от 6 до 25 и обнаружил 20 последовательных неиспользованных адресов. По правилу разрыва BIP-44 поиск останавливается на 25; использованный адрес 26 оказывается за условием остановки и пропускается. Расширение поиска до явной документированной границы может его найти, но причина в том, что исходный кошелёк создал адрес за стандартным разрывом без промежуточной активности.

Подсчёт ограниченного поиска восстановления

Запись о восстановлении не указывает, какая из 4 семейств назначения Bitcoin (44', 49', 84' и 86') применялась, а также какой из 3 аккаунтов, 2 ветвей и первых 20 индексов использован. Начальный поиск содержит 4 × 3 × 2 × 20 = 480 конечных кандидатов. Совпадение знакомого адреса определяет путь-кандидат, но не обязательно весь кошелёк: ещё проверяются сдача, последующие индексы, другие аккаунты, дескриптор и история. Явные измерения делают поиск воспроизводимым и ограничивают перебор.

Почему xpub аккаунта не является обычными публичными данными

Для неусиленного дочернего ключа BIP-32 приватные скаляры связаны формулой child = parent + tweak (mod n). В упрощённом примере по модулю 101, если данные деривации из расширенного публичного ключа аккаунта задают tweak = 37, а приватный дочерний скаляр 12 утёк, то parent = 12 - 37 mod 101 = 76. Настоящий BIP-32 использует порядок группы secp256k1 и значения HMAC, но алгебраическое следствие то же: родительский xpub и соответствующий неусиленный приватный ключ потомка могут раскрыть расширенный родительский приватный ключ и его поддерево. Усиленные границы аккаунтов ограничивают этот сбой.

Риски и ошибки проверки

  • Неверная мнемоническая фраза или парольная фраза: Другое слово, порядок слов, правило нормализации Unicode или парольная фраза создают иной корневой ключ, который может выглядеть допустимым.
  • Неверная схема деривации: Применение BIP-32 к кошельку с другой мнемонической схемой, кривой, KDF или алгоритмом мастер-ключа даёт несвязанные ключи.
  • Неверная сеть или тип монеты: Корректный корневой ключ в другом пространстве имён может создавать правдоподобные адреса, тогда как нужная сеть останется непроверенной.
  • Неверное назначение или скрипт: Путаница между 44', 49', 84' и 86' может исключить тот тип выходов Bitcoin, где действительно находятся средства.
  • Отсутствующая отметка усиленной деривации: 7, 7', 7h и 7H могут интерпретироваться иначе или отклоняться; усиленные и обычные дочерние ключи невзаимозаменяемы.
  • Неверный индекс аккаунта: Проверка только аккаунта 0' может пропустить средства или полномочия в последующих логических аккаунтах.
  • Путаница внешней ветви и ветви сдачи: Сканирование только ветви 0 может пропустить выходы сдачи в ветви 1 или особую структуру ветвей кошелька.
  • Неверный индекс адреса: Совпадение первого известного адреса не доказывает проверку последующих, пропущенных или импортированных адресов.
  • Ошибка разрыва адресов: 20 последовательных неиспользованных внешних адресов могут остановить поиск BIP-44 до более позднего нестандартного использования.
  • Пропущенный аккаунт: Последовательный поиск может остановиться на неиспользованном аккаунте и не дойти до аккаунта, созданного после него.
  • Неполная политика Bitcoin: Без дескриптора, скриптов, порога, порядка ключей, отпечатков и контрольной суммы путь может не восстановить финансируемые выходы.
  • Особое соглашение кошелька: Приложение может использовать старую, проприетарную или миграционную структуру, которой нет в универсальном средстве восстановления.
  • Утечка приватности расширенного публичного ключа: xpub может раскрыть группы адресов, историю, балансы и будущие неусиленные дочерние адреса.
  • Чрезмерное раскрытие расширенного приватного ключа: Импорт xprv может открыть всё поддерево, а не только один лист, нужный для операции.
  • Компрометация родительского ключа BIP-32: Родительский xpub вместе с соответствующим неусиленным дочерним приватным ключом может раскрыть расширенный родительский приватный ключ и его поддерево.
  • Ложная уверенность в формате адреса: Синтаксически допустимый адрес не доказывает правильность seed, пути, сети, скрипта или владельца.
  • Путаница сетей с одинаковым адресом: Один ключ EVM может давать одинаковый адрес в нескольких сетях, но балансы, nonce, токены и риски в них различны.
  • Вредоносное средство восстановления: Сайт, расширение, демонстрация экрана, монитор буфера, регистратор или поддельное устройство могут похитить корневой секрет.
  • Путаница импорта и sweep: Импорт сохраняет старые полномочия; sweep или миграция создают транзакцию, поэтому нужно проверить комиссию и назначение.
  • Неполное восстановление: Один найденный баланс без проверки подписей, сдачи, токен-контрактов, ролей, разрешений, ключей валидаторов и резервных копий может оставить активы скрытыми или уязвимыми.

Распространённые заблуждения

Является ли путь деривации паролем или секретом?

Нет. Путь обычно описывает публичную структуру и должен сохраняться как метаданные для восстановления. Он не заменяет мнемоническую фразу, пароль, seed, приватный ключ или политику кошелька. Публикация пути может раскрыть организационную информацию, но само по себе обладание путем не предоставляет права подписи.

Всегда ли одна мнемоническая фраза автоматически восстанавливает один кошелёк?

Нет. Результат также зависит от схемы мнемоники, точной парольной фразы, обработки сид-фразы, алгоритма деривации, пути, кривой, сети и способа построения адреса или скрипта. Программное обеспечение кошелька может выбирать разные значения по умолчанию, даже если оно принимает одни и те же слова.

Запрещает ли тип монеты использовать ключ в другой сети?

Нет. Тип монеты — это пространство имён деривации и соглашение о совместимости, а не протокольное разрешение. Программное обеспечение может деривировать или повторно использовать ключ в другом месте, а сети EVM обычно дают один и тот же адрес аккаунта для одного приватного ключа.

Доказывает ли пустой восстановленный аккаунт исчезновение активов?

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

Может ли инструмент восстановления безопасно проверить все возможные пути?

Нет. Пространство поиска может быть большим, правила использования кошельков не полностью универсальны, а раскрытие корневого секрета ненадежному инструменту само по себе является событием потери. Используйте происхождение, зарегистрированные отпечатки и адреса, ограниченный офлайн-поиск и проверенное программное обеспечение, чтобы сузить поиск.

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

Источники

Навигация

Поиск по вики...