Как проверить, какие сети поддерживает ваш адрес и разграничить доступ: разведите активы по контурам на уровне аккаунта деривации, а затем проверьте, какие сети подняты в каждом контуре. Граница доступа проходит не по сети, а по аккаунту: усиленная деривация не позволяет из одного аккаунта вывести ключи другого. Проверка сводится к таблице «контур — аккаунт — сети — кто видит».

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

Под какой сценарий подбирается кошелёк

Разграничение нужно там, где у одного владельца разные роли. Часть средств лежит годами. Часть расходуется каждую неделю. Часть показывается бухгалтеру или партнёру. Смешивать их в одном аккаунте неудобно и небезопасно: любая утечка публичных данных раскрывает весь объём сразу.

Стандарт даёт готовый механизм. BIP-32, принятый 11 февраля 2012 года, вводит усиленную деривацию и прямо указывает, что усиленные ключи применяются на уровне аккаунта, чтобы утечка нижележащих ключей не компрометировала ни мастер-ключ, ни соседние аккаунты (текст BIP-32, сверено 15 октября 2026 года). Граница встроена в стандарт. Остаётся ею воспользоваться.

Отсюда план. Разложить активы по аккаунтам, назначить каждому аккаунту роль и зафиксировать, какие сети в нём включены.

Сравнение типов: что меняется для пользователя

Структура пути по BIP-44 от 24 апреля 2014 года содержит уровень аккаунта между типом монеты и порядковым номером адреса. Это и есть точка разреза. Сети внутри одного аккаунта делят общую судьбу: тот, кто получил подписывающий доступ к аккаунту, распоряжается всем, что в нём лежит, независимо от числа поднятых цепей.

Контур Какие сети поднимаются Какой доступ передаётся Как проверяется граница
Хранилищный, долгие остатки Одна-две сети, где актив лежит без движения Никакого, кроме владельца Отсутствие аккаунта в рабочих приложениях
Операционный, текущие расходы Сети, в которых идут регулярные переводы Подпись у владельца, запас газа в каждой сети Тестовым переводом по каждой сети
Наблюдательный, отчётность Те же сети, что в операционном Расширенный публичный ключ без права подписи Сверкой видимых адресов с рабочими
Экспериментальный, новые протоколы Сети, где вы пробуете незнакомые приложения Подпись у владельца, малые остатки Отдельным аккаунтом и отдельным устройством

Настройка шаг за шагом

  1. Перечислите роли, которые нужны на практике: хранение, операции, отчётность, эксперименты.
  2. Назначьте каждой роли отдельный номер аккаунта в пути деривации.
  3. Для каждого аккаунта выпишите сети, которые в нём должны быть подняты, с идентификаторами цепей.
  4. Поднимите в приложении только эти сети. Лишние записи увеличивают площадь ошибки.
  5. Передайте наблюдательный доступ там, где нужна видимость без распоряжения.
  6. Проверьте каждый контур отдельно: какие сети видны, какие подписываются, где лежит газ.
  7. Зафиксируйте таблицу и укажите дату следующей сверки.
Расширенный публичный ключ нельзя хранить рядом с приватными ключами его ветви. По предупреждению BIP-32, знание такого ключа вместе с любым производным приватным ключом равносильно знанию родительского приватного ключа — то есть раскрывает весь контур целиком.

Резервная копия и проверка восстановления

Рабочая схема для частного владельца: 3–4 аккаунта, в каждом от одной до пяти поднятых сетей, одна резервная фраза на все контуры, отдельная парольная фраза для хранилищного аккаунта. Сверка таблицы — раз в квартал и после каждой передачи доступа.

Резервная копия у всех контуров общая, если они выведены из одной фразы. Это удобно для хранения и опасно для разграничения: восстановив фразу, человек получает доступ ко всем аккаунтам сразу. Поэтому контур с долгими остатками часто выносят под отдельную парольную фразу, и тогда у него появляется собственное зерно.

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

Схема из пяти шагов: перечень ролей, назначение номера аккаунта каждой роли, список сетей для контура, передача наблюдательного доступа, поконтурная сверка после восстановления
Схема из пяти шагов: перечень ролей, назначение номера аккаунта каждой роли, список сетей для контура, передача наблюдательного доступа, поконтурная сверка после восстановления

Типовые ошибки, которые стоят денег

  • Разграничение сделано по сетям, а не по аккаунтам. Доступ к ключу открывает все цепи сразу.
  • Наблюдательный ключ передан вместе с одним приватным ключом из той же ветви.
  • Экспериментальный контур живёт в том же аккаунте, что и хранилищный.
  • Таблица контуров есть, но номера аккаунтов в ней не записаны.
  • В операционном контуре подняты сети, которыми не пользуются, и это усложняет проверку.
  • Парольная фраза хранилищного контура записана там же, где основная.

Из обращений читателей складывается типичная картина. Человек заводит «отдельный кошелёк» под эксперименты, но делает его первым аккаунтом той же фразы, где лежат долгие остатки. Подпись в незнакомом приложении касается только одного адреса, однако утечка фразы при настройке касается уже всех контуров.

Что делать при утере доступа

Если утрачено устройство, восстанавливайте по таблице контуров: она подсказывает номера аккаунтов и перечни сетей, которые нужно поднять заново. Проверяйте каждый контур отдельно, начиная с операционного, где движение средств заметнее всего.

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

Чек-лист

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

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

Частые вопросы

Почему граница проходит по аккаунту, а не по сети?

Сети одного семейства используют один и тот же ключ, поэтому разделение по цепям ничего не разграничивает. Уровень аккаунта в пути деривации выводится усиленно: из одного аккаунта нельзя получить ключи другого. Это свойство стандарта, а не настройка приложения.

Можно ли сделать контуры на одной резервной фразе?

Можно, и это удобно для хранения копии. Минус в том, что фраза открывает все аккаунты сразу. Для контура с долгими остатками разумно добавить отдельную парольную фразу: она даёт другое зерно, и такой контур перестаёт зависеть от компрометации основного набора.

Сколько сетей держать в одном контуре?

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

Чем опасна передача расширенного публичного ключа?

Сам по себе он не позволяет тратить средства, но раскрывает все адреса ветви и историю операций. Опаснее сочетание: такой ключ вместе с любым производным приватным ключом даёт родительский приватный ключ. Поэтому их хранят раздельно и никогда не передают одному адресату.

Вердикт

Разграничение доступа начинается не с отдельных приложений, а с уровня аккаунта в пути деривации — именно там стандарт проводит границу, через которую ключи не проходят. Сети внутри контура общую судьбу делят, и это стоит учитывать при выборе, какие цепи поднимать. Таблица «контур — аккаунт — сети — кто видит» умещается на одном листе и заменяет десяток устных договорённостей.

Разборы по хранению публикуются в нашем Telegram-канале Cryptium.

Источники: текст стандарта BIP-32 об иерархических детерминированных кошельках и текст стандарта BIP-44 о структуре аккаунтов.