Объяснение разницы между закрытыми и открытыми ключами

В чём разница между закрытым и открытым ключом?

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

Упрощённое объяснение для новичков — «открытый ключ принимает, закрытый ключ тратит» — указывает в правильном направлении, но с технической точки зрения слишком общее. Открытый ключ обычно проверяет подписи; адрес, выход или счёт принимает средства. Закрытый ключ может быть единственным полномочным элементом для простого счёта, одним из подписантов в схеме с несколькими подписями, долей в системе с пороговым значением или не иметь отношения к адресу контракта, контроль над которым определяет его код.

Что же такое закрытый ключ?

Личный ключ — это не имя пользователя, не пароль к учетной записи и не код поддержки. Это секретный математический входной параметр, позволяющий подписавшемуся лицу создать доказательство, совпадающее с открытым ключом. В сетях Bitcoin и Ethereum для обычных пользовательских подписей используется эллиптическая кривая secp256k1. Допустимый закрытый ключ secp256k1 представляет собой скаляр в группе кривой, который обычно хранится в 32 байтах. Системы Ed25519, такие как Solana, обычно начинают с 32-байтового секретного семененного числа и выводят скаляр для подписи и открытый ключ в соответствии с правилами EdDSA.

Такие описания, как «случайное 256-битное число», полезны для secp256k1, но не должны рассматриваться как универсальное определение кошелька. Ключи также встречаются в различных кодировках: шестнадцатеричной, формате импорта кошелька (Wallet Import Format), зашифрованных хранилищах ключей, объектах ключей с аппаратной поддержкой или неэкспортируемых учетных данных операционной системы. Кодировка — это контейнер или представление; источником подписи является лежащий в основе секрет.

Качество генерации имеет значение

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

Реализации подписи также должны правильно обрабатывать нонс для каждого сообщения. В ECDSA повторное использование или сильное смещение этого секретного нонса может привести к раскрытию закрытого ключа, даже если долгосрочный ключ был сгенерирован идеально. Детерминированные процедуры ECDSA, такие как RFC 6979, снижают зависимость от свежих случайных нонсов, однако реализациям по-прежнему необходима защита от побочных каналов и сбоев.

Секретный ключ не всегда равен всему счету

В случае простого счёта Ethereum, принадлежащего внешнему владельцу, владения ключом достаточно для подписания любой транзакции, разрешённой протоколом. Для вывода в сети Bitcoin ключ полезен только в том случае, если он соответствует скрипту вывода. Для вывода с мультиподписью может потребоваться несколько ключей. Счёт контракта Ethereum не имеет собственного закрытого ключа; код определяет, какие вызовы или подписи принимаются. Адрес, сгенерированный программой Solana, вообще не имеет закрытого ключа.

Вывод: утверждение «Тот, у кого есть закрытый ключ, владеет средствами» верно для счета с одним ключом, но не является универсальным определением владения в блокчейне. Фактические полномочия определяются тем, что подтверждает счет, скрипт вывода или программа.

Что такое открытый ключ?

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

Открытые ключи имеют несколько форматов кодирования. Ключи Bitcoin secp256k1 могут представляться в виде сжатых точек длиной 33 байта, более старых несжатых точек длиной 65 байтов или 32-байтовых ключей, состоящих только из знаков «x», для BIP340 Schnorr. Инструменты Ethereum обычно внутренне вычисляют несжатый открытый ключ secp256k1, даже если пользователи взаимодействуют с 20-байтовым адресом. Открытые ключи Solana Ed25519 имеют размер 32 байта и обычно отображаются в формате base58.

Чего не доказывает открытый ключ

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

Является ли адрес кошелька тем же, что и открытый ключ?

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

В документации для разработчиков Bitcoin часто в общем плане говорится о распространении открытых ключей, при этом отмечается, что кошельки обычно распространяют вместо них хеши открытых ключей или хеши скриптов. Ethereum проводит различие между внешними счетами и счетами контрактов. Solana явно поддерживает как адреса с открытыми ключами Ed25519, так и адреса вне кривой, полученные из программы.

Формата адреса недостаточно

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

Как работают цифровые подписи — и что они доказывают?

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

Подпись — это не шифрование

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

Подпись без комиссии за газ всё равно может впоследствии переместить стоимость

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

Откуда берутся криптографические ключи?

Ранние кошельки генерировали и сохраняли множество несвязанных между собой закрытых ключей. Иерархические детерминированные кошельки изменили эту модель: корневое семя и цепочка кода формируют дерево дочерних ключей. Стандарт BIP32 унифицировал этот подход для систем, совместимых с Bitcoin, включая ветви, содержащие только открытые ключи, которые могут генерировать адреса для получения средств без раскрытия ключей для расходования.

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

Генерация ключей должна быть проверяемой и воспроизводимой

Кошелек должен использовать криптографически безопасный генератор случайных чисел, сохранять достаточное количество резервной информации и чётко объяснять процесс восстановления. Аппаратные кошельки могут генерировать и хранить секрет внутри специального устройства. Мобильные кошельки могут полагаться на безопасное хранилище операционной системы. Пороговые кошельки могут совместно генерировать доли таким образом, чтобы полный закрытый ключ никогда не собирался воедино. Это различные архитектуры хранения, а не просто разные интерфейсы.

Является ли фраза восстановления тем же, что и закрытый ключ?

Называть фразу «секретным ключом в словах» — это запоминающееся, но с технической точки зрения вводящее в заблуждение. Типичный детерминированный кошелек содержит множество секретных ключей. Фраза представляет собой удобочитаемый для человека резервный ввод для корня, из которого производятся эти ключи. Стандарт BIP39 допускает использование 12, 15, 18, 21 или 24 слов в зависимости от требуемого уровня энтропии, хотя 12 и 24 слова являются наиболее распространёнными форматами для потребителей. Не все кошельки используют BIP39, а некоторые системы с хранением активов или «умные» счета вообще не предоставляют мнемонической фразы.

Не забудьте опциональную парольную фразу

Парольная фраза BIP39 иногда позиционируется как «25-е слово», но на самом деле это может быть любая поддерживаемая строка, которая не хранится внутри мнемонической фразы. Её потеря может привести к тому, что кошелек станет невозможным для восстановления, даже если слова указаны правильно. Поэтому запись слов без указания типа кошелька, политики парольной фразы и инструкций по восстановлению может привести к созданию резервной копии, которая выглядит полной, но таковой не является.

Содержит ли один кошелек только одну пару ключей?

Биткойн-кошелек часто генерирует новые адреса для получения и сдачи, чтобы сократить повторное использование адресов и управлять моделью UTXO. Каждый адрес может соответствовать отдельному дочернему ключу или скрипту. Кошелек Ethereum обычно отображает несколько внешних учетных записей, созданных на основе одной фразы, каждая из которых имеет собственный закрытый ключ и адрес. Кошелек Solana может управлять несколькими парами ключей и учетными записями токенов. Учетная запись на бирже может отображать баланс, не предоставляя клиенту никаких закрытых ключей блокчейна.

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

Чем отличаются Bitcoin, Ethereum и Solana?

Ethereum после Pectra: делегирование — это не замена ключа

EIP-7702 позволяет EOA в Ethereum делегировать выполнение коду, обеспечивая функции, аналогичные «умным» счетам. Тем не менее, частный ключ EOA сохраняет полные полномочия и может заменить или отменить делегирование. Делегирование EOA коду, работающему по принципу мультиподписи, не превращает базовый ключ EOA в истинное пороговое требование.

Почему названия алгоритмов имеют значение

ECDSA, Schnorr и EdDSA — все они генерируют цифровые подписи, но их кодировки, правила nonce, свойства агрегации и процедуры проверки различаются. Нельзя считать, что ключ или подпись одной схемы совместимы с другой только потому, что обе используют 32-байтовые значения. Сетевое программное обеспечение точно определяет, какие алгоритмы и кодировки являются допустимыми.

Безопасно ли делиться открытым ключом или адресом кошелька?

Открытые ключи существуют для того, чтобы быть общедоступными, а адреса — для того, чтобы их распространять. Человек, знающий ваш адрес Bitcoin, адрес Ethereum или открытый ключ Solana, не может просто вычислить закрытый ключ с помощью современных классических вычислительных методов. Однако он может отслеживать публичную активность, связанную с этим идентификатором, и сопоставлять её с записями бирж, постами в социальных сетях, доменными именами или утечками данных.

То, что раскрывает адрес, зависит от способа его использования

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

Безопасный приём средств

• Делитесь адресом через канал, соответствующий уровню риска, и независимо подтверждайте адреса получателей крупных сумм.
• Указывайте сеть и актив, а не просто строку символов. Один и тот же адрес EVM может существовать в нескольких сетях.
• Не копируйте повторяющихся получателей из истории транзакций без проверки; переводы с «отравлением адреса» предназначены для внедрения похожих записей.
• При переводах крупных сумм проверяйте полный адрес получателя на надежном устройстве отображения. Проверки только первых и последних нескольких символов недостаточно для защиты от целенаправленных подделок.
• Рассмотрите возможность проведения тестовой транзакции, если это целесообразно с операционной точки зрения, а затем подтвердите получение через отдельный канал, прежде чем отправлять остаток.
• Избегайте публичной привязки крупных активов к вашему официальному имени, месту жительства или графику поездок.

Что делать, если частный ключ или фраза восстановления попали в чужие руки?

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

Последовательность немедленных действий

• Прекратите использование устройства или сеанса браузера, которые, возможно, подверглись взлому. Не переходите по ссылкам для восстановления, отправленным кем-либо, кто свяжется с вами.
• На «чистом» устройстве инициализируйте новый кошелек или политику подписания с использованием новых секретных данных. Независимо проверьте программное обеспечение, сеть и резервную копию для восстановления.
• Переместите ценные активы или замените подписанта в соответствии с архитектурой счета. Скомпрометированный ключ создает ситуацию гонки; тщательно расставьте приоритеты для активов и собственных токенов комиссии.
• Что касается одобрений токенов Ethereum, помните, что одного отзыва недостаточно для устранения утечки закрытого ключа: злоумышленник может подписывать новые транзакции. Передайте полномочия или переместите активы.
• Проверьте каждую сеть, в которой использовался тот же ключ или фраза, включая тестовые учетные записи, сети второго уровня и менее заметные остатки токенов.
• Сохраните хеши транзакций, адреса, сообщения и доказательства с устройств. Незамедлительно сообщите о краже соответствующим хранителям, биржам и правоохранительным органам.
• Не доверяйте тем, кто обещает гарантированное восстановление за авансовую плату. Мошенники, предлагающие услуги по восстановлению, систематически выбирают в качестве мишеней известных жертв.

Что произойдет в случае потери закрытого ключа?

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

Преемственность и утрата дееспособности

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

Можно ли изменить, разделить или заменить закрытый ключ?

С точки зрения практической безопасности кошелька независимо сгенерированный запасной ключ имеет другой открытый ключ, а поиск другого ключа, сохраняющего усечённый идентификатор адреса, является вычислительно невыполнимым в рамках предполагаемых допущений о безопасности. Таким образом, для обычного одноключевого выхода в сети Биткойн или EOA в сети Ethereum ротация ключей означает перевод средств на новый адрес назначения. Обновляемая политика «умного» счёта может заменить уполномоченного подписанта без изменения адреса счёта. Политика с мультиподписью может потребовать проведения транзакции для установления нового набора подписантов.

Мультиподпись в цепочке

Блокчейн проверяет политику, требующую нескольких независимых подписей или одобрений по контракту. Политика может быть видимой в цепочке, хотя Taproot может скрывать неиспользуемые пути скриптов до момента расходования средств. Мультиподпись обеспечивает прозрачное соблюдение правил и специфические для цепочки варианты восстановления, но она может стоить дороже и раскрывать операционную структуру.

Пороговые подписи и MPC

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

«Умные» счета и ключи-пароли

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

Что защищают аппаратные кошельки?

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

Важные ограничения

• Компрометация фразы восстановления обходит устройство. Любой, кто владеет этой фразой, может воссоздать ключи в другом месте.
• «Слепое» или нечитаемое подписание может привести к авторизации вредоносных одобрений, разрешений или вызовов контрактов, даже если ключ никогда не покидает устройство.
• Подмена адреса получателя на компьютере может увенчаться успехом, если пользователь подтвердит её, не проверив отображение на экране устройства.
• Прошивка, цепочка поставок, физический доступ и процедуры резервного копирования по-прежнему остаются частью модели угроз.
• Один аппаратный кошелек в сочетании с одной фразой по-прежнему может представлять собой единственную точку отказа. Конструкции с мультиподписью или пороговыми значениями решают иную проблему.
• Ни одно устройство не защищает от риска изменения цен на активы, мошеннических контрагентов, взломанных смарт-контрактов или ошибочного выбора сети.

Вывод: аппаратная изоляция ценна, но «ключи оставались в автономном режиме» — это не то же самое, что «транзакция была безопасной». Доверенный дисплей и решение пользователя о подтверждении являются частью границы безопасности.

Что означают квантовые компьютеры для криптографических ключей?

В стандарте FIPS 186-5 NIST прямо отмечается, что его классические алгоритмы подписи, как ожидается, не смогут противостоять крупномасштабному квантовому компьютеру. NIST отдельно стандартизировал постквантовые подписи, включая ML-DSA и SLH-DSA. Эти стандарты не обеспечивают автоматическое обновление блокчейна: каждой сети требуются совместимые адреса, механизм проверки подписей, поддержка кошельков и путь миграции для существующих средств.

Часто повторяемое утверждение о том, что «неиспользуемые адреса являются квантово-безопасными, поскольку публичным является только хеш», не является универсально достоверным. Типы адресов различаются: выходные ключи Taproot и открытые ключи подписантов Solana остаются видимыми, открытые ключи Ethereum часто можно восстановить из подписей после использования, а средства могут быть перемещены или раскрыты различными способами. Хеширование может задержать некоторые формы раскрытия открытых ключей, но не является полноценной стратегией миграции.

Что пользователям следует делать сейчас

• Не поддавайтесь панике и не переводите средства в непроверенные «квантово-безопасные» продукты, которые продвигаются с использованием эффекта срочности.
• Обеспечьте поддержку программного обеспечения кошелька и устройств подписи, чтобы они могли использовать будущие инструменты миграции сети.
• Избегайте ненужного повторного использования адресов в тех случаях, когда модель кошельков сети рекомендует создавать новые адреса.
• Следуйте официальным рекомендациям по протоколу и кошелькам, если будет объявлена миграция; самостоятельно проверяйте пункты назначения и сроки.
• В случае долгосрочного институционального хранения включите в план управления криптографическую гибкость и полномочия по миграции.

Часто задаваемые вопросы

Что такое закрытый ключ, если описать одним предложением?

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

Что такое открытый ключ, если описать одним предложением?

Открытый ключ — это данные для проверки, полученные на основе закрытого ключа. Он позволяет любому пользователю проверять соответствие подписей, не узнавая закрытый ключ и не получая возможности подписывать.

Является ли адрес кошелька тем же, что и открытый ключ?

Как правило, нет. Адрес может кодировать открытый ключ, хэш открытого ключа, скрипт или программу-свидетеля, идентификатор контракта или адрес, полученный с помощью программы. В Solana стандартный адрес подписанта — это сам открытый ключ; в Ethereum адреса контрактов не имеют соответствующего закрытого ключа.

Может ли кто-то украсть криптовалюту, зная только адрес моего кошелька?

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

Может ли кто-то вычислить мой закрытый ключ по открытому?

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

Является ли фраза-семенная фраза тем же, что и закрытый ключ?

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

В чём разница между паролем кошелька и приватным ключом?

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

Могу ли я изменить свой закрытый ключ, не меняя адрес?

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

Почему мой биткойн-кошелек генерирует новый адрес?

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

Стоит ли делиться расширенным открытым ключом?

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

Хранит ли аппаратный кошелек мои монеты?

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

Вывод

Закрытые ключи, открытые ключи, адреса и фразы восстановления связаны между собой, но они не взаимозаменяемы. Закрытый ключ или доля подписи создает полномочия. Открытый ключ подтверждает их. Адрес определяет пункт назначения в сети или условия расходования средств. Система восстановления воссоздает или заменяет полномочия в случае выхода из строя исходного устройства. Путаница в этих уровнях приводит как к неверным объяснениям, так и к дорогостоящим ошибкам.

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

Источники и дополнительная литература

Основные источники для данной статьи, актуальные по состоянию на июль 2026 года.

• NIST FIPS 186-5 — Стандарт цифровой подписи. https://csrc.nist.gov/pubs/fips/186-5/final
• Руководство для разработчиков Bitcoin — Кошельки. https://developer.bitcoin.org/devguide/wallets.html
• Руководство для разработчиков Bitcoin — Транзакции. https://developer.bitcoin.org/devguide/transactions.html
• BIP 340 — Подписи Шнорра для secp256k1. https://bips.dev/340/
• BIP 341 — Taproot: правила расходования средств в SegWit версии 1. https://bips.dev/341/
• BIP 32 — Иерархические детерминированные кошельки. https://bips.dev/32/
• BIP 39 — Мнемонический код для генерации детерминированных ключей. https://bips.dev/39/
• Ethereum.org — Учетные записи Ethereum. https://ethereum.org/developers/docs/accounts/
• Ethereum.org — Безопасность и предотвращение мошенничества. https://ethereum.org/security/
• Ethereum.org — Рекомендации по Pectra EIP-7702. https://ethereum.org/roadmap/pectra/7702/
• Документация Solana — Структура учетной записи. https://solana.com/docs/core/accounts
• Документация Solana — Программно-производные адреса. https://solana.com/docs/core/pda
• RFC 8032 — Алгоритм цифровой подписи на кривой Эдвардса. https://www.rfc-editor.org/info/rfc8032/
• NIST FIPS 204 — Стандарт цифровой подписи на основе модульно-решеточной схемы. https://csrc.nist.gov/pubs/fips/204/final