Четыре объекта отвечают на четыре разных вопроса
| Объект | Для чего нужен | Можно ли раскрывать |
|---|---|---|
| Приватный ключ | Создаёт криптографическое разрешение на действие | Нет: получивший секрет может подписывать от имени этого ключа |
| Публичный ключ | Позволяет проверить подпись и участвует в получении адреса | Обычный ключ публичен по назначению; xpub раскрывает целую ветку адресов и требует отдельной защиты приватности |
| Адрес | Указывает сети, кому или по какому правилу предназначен актив | Да: его сообщают отправителю, учитывая потерю приватности |
| Подпись | Связывает конкретные данные с контролем приватного ключа | Обычно да, но только вместе с точным контекстом подписанного сообщения |
- Объект
- Приватный ключ
- Для чего нужен
- Создаёт криптографическое разрешение на действие
- Можно ли раскрывать
- Нет: получивший секрет может подписывать от имени этого ключа
- Объект
- Публичный ключ
- Для чего нужен
- Позволяет проверить подпись и участвует в получении адреса
- Можно ли раскрывать
- Обычный ключ публичен по назначению; xpub раскрывает целую ветку адресов и требует отдельной защиты приватности
- Объект
- Адрес
- Для чего нужен
- Указывает сети, кому или по какому правилу предназначен актив
- Можно ли раскрывать
- Да: его сообщают отправителю, учитывая потерю приватности
- Объект
- Подпись
- Для чего нужен
- Связывает конкретные данные с контролем приватного ключа
- Можно ли раскрывать
- Обычно да, но только вместе с точным контекстом подписанного сообщения
Пароль разблокирует приложение или зашифрованный файл на устройстве. Приватный ключ выполняет другую роль: алгоритм использует его, чтобы получить подпись под транзакцией или сообщением. Сеть не просит раскрыть секрет — ей достаточно подписи и открытых данных. Поэтому настоящий кошелёк подписывает внутри приложения или устройства, а сайт, поддержка и получатель не должны получать ключ или seed-фразу. Перед подтверждением отдельно проверьте, что именно просит подписать кошелёк.
Связь по цепочке не означает равенство
В типичной схеме приватный ключ определяет публичный. Адрес затем получают из публичного ключа или script по правилам сети: Ethereum берёт часть Keccak-256 hash публичного ключа, а Bitcoin поддерживает несколько script- и address-форматов. Поэтому нельзя универсально говорить, что адрес — это публичный ключ. Один и тот же секрет также способен участвовать в создании разных представлений адреса в зависимости от протокола и формата.
Публичный адрес помогает получить перевод и проверить видимую историю, но раскрывает связи между операциями. Если адрес опубликован в счёте, чате или профиле, наблюдатель может сопоставлять его с другими открытыми данными. Отдельная проверка нужна, чтобы понять, что действительно видно по адресу и где заканчивается допустимый вывод.
Подпись доказывает контроль, но не все утверждения вокруг него
Проверяющий берёт точные подписанные данные, подпись и открытые параметры. Успех проверки означает: подпись могла быть создана ключом, соответствующим проверяемому аккаунту, а данные после подписания не изменились. Это не доказывает, что подписант прочитал интерфейс, является названным человеком, имеет законное право на актив или согласен с текстом вне подписанного payload.
| Проверка | Допустимый вывод | Лишний вывод |
|---|---|---|
| Подпись транзакции | Ключ разрешил конкретную сетевую операцию | Владелец одобрил любой результат приложения |
| Подпись сообщения | Ключ подписал конкретные байты или structured data | Подписант раскрыл паспортную личность |
| Login with wallet | Сайт проверил challenge и адрес | Сайт получил право тратить токены |
| Подпись smart account | Контракт принял настроенное правило авторизации | У аккаунта обязательно один приватный ключ |
- Проверка
- Подпись транзакции
- Допустимый вывод
- Ключ разрешил конкретную сетевую операцию
- Лишний вывод
- Владелец одобрил любой результат приложения
- Проверка
- Подпись сообщения
- Допустимый вывод
- Ключ подписал конкретные байты или structured data
- Лишний вывод
- Подписант раскрыл паспортную личность
- Проверка
- Login with wallet
- Допустимый вывод
- Сайт проверил challenge и адрес
- Лишний вывод
- Сайт получил право тратить токены
- Проверка
- Подпись smart account
- Допустимый вывод
- Контракт принял настроенное правило авторизации
- Лишний вывод
- У аккаунта обязательно один приватный ключ
Seed-фраза, ключ, аккаунт и кошелёк тоже не одно и то же
Seed-фраза в совместимой HD-схеме служит исходными данными, из которых кошелёк выводит дерево ключей. Один backup способен восстановить множество аккаунтов, но результат зависит от стандарта, derivation path и реализации кошелька. Само приложение — интерфейс и key-management software; удаление приложения не удаляет блокчейн, а восстановление по неверному пути может показать другой набор адресов. Поэтому заранее решите, как хранить seed-фразу и как выбрать модель кошелька под свой риск-профиль.
Безопасная граница в обычной операции
- получателю отправляют адрес и явно называют сеть;
- приватный ключ и seed-фразу не вводят в форму проверки и не пересылают поддержке;
- перед подписью сверяют сеть, адрес контракта, действие, сумму и срок действия;
- для доказательства контроля подписывают одноразовый challenge с доменом и назначением, а не произвольный текст из чата;
- после проверки сохраняют точные подписанные данные, потому что одна подпись без payload неоднозначна.
У smart account полномочия могут задаваться кодом: несколькими signers, лимитами, временными ключами или recovery-механизмом. Тогда вопрос «какой приватный ключ владеет адресом» слишком груб. Сначала нужно установить тип аккаунта и фактическое правило авторизации.
Источники
Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.
- Ethereum.org — Ethereum accounts Ethereum Foundation · Проверено 18 августа 2026 г. в 22:28 GMT+5
- Bitcoin Developer Guide — Wallets Bitcoin Project · Проверено 18 августа 2026 г. в 22:28 GMT+5
- Ethereum.org — Keys in proof-of-stake Ethereum Ethereum Foundation · Проверено 18 августа 2026 г. в 22:28 GMT+5