﻿---
title: "Подпись кошелька"
description: "Подпись кошелька доказывает, что ключ или контрактный аккаунт одобрил точные данные по заданным правилам проверки. Различия сообщений, транзакций, разрешений, повторов и фишинга."
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.

# Подпись кошелька

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

<a id="answer"></a>

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

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

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

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

<a id="mechanism"></a>

## Как это работает

1. Приложение кодирует транзакцию, обычное сообщение или типизированные данные. Даже малое изменение даёт другой дайджест.
2. Кошелёк показывает то, что может декодировать, и запрашивает согласие. Закрытый ключ остаётся в кошельке или устройстве; возвращается подпись дайджеста.
3. Проверяющий воссоздаёт тот же дайджест. Для внешнего аккаунта обычно восстанавливается или сверяется адрес; контрактный аккаунт может применить текущую политику через ERC-1271.
4. Результат толкуется по правилам приложения. Сервер может создать сеанс; контракт — использовать permit, исполнить ордер, изменить управление или выполнить другой разрешённый вызов.
5. Защита от повтора зависит от приложения. EIP-712 даёт типизированное кодирование и разделение доменов, но не защиту от повтора; приложение должно обеспечить nonce, deadline, предполагаемого проверяющего, сеть или иную одноразовую границу.

ERC-191 отделяет подписанные данные от обычного кодирования транзакций Ethereum и определяет форматы, включая `personal_sign`. EIP-712 связывает структурированные поля с доменом, который может включать `name`, `version`, `chainId` и `verifyingContract`. Сообщения входа ERC-4361 добавляют домен, URI, ID сети, nonce и время выпуска, но сервис обязан также их проверить.

<a id="example"></a>

## Пример

Leah получает на официальном сервисе запрос входа ERC-4361 с ожидаемыми доменом и URI, новым nonce и коротким сроком. Запрошена только аутентификация. После проверки она подписывает; сервер проверяет сообщение и создаёт сеанс. Само сообщение не создаёт allowance токена или транзакцию в сети.

На поддельном сайте кнопка всё ещё гласит «Войти», но кошелёк показывает данные EIP-712 `Permit` с токеном, spender, суммой, nonce и deadline. Подпись может позволить ретранслятору создать право расходования по правилам контракта. Leah должна отказаться: надпись кнопки не меняет подписываемые байты.

<a id="risks"></a>

## Риски и меры защиты

- **Обман смысла:** сайт может назвать permit или ордер входом. Доверяйте декодированным данным и проверенному контракту, а не кнопке.
- **Слепая подпись:** сырые хеши и непрозрачные байты мешают осмысленной проверке. Отмените, если точное сообщение и путь исполнения нельзя воспроизвести надёжным инструментом.
- **Неверный домен:** знакомый бренд не подтверждает `chainId`, `verifyingContract`, веб-домен или URI. Независимо проверьте каждое поле и полный адрес.
- **Повтор или позднее исполнение:** обладатель подписи может использовать её до расходования nonce или истечения deadline. Используйте новые nonce и короткие сроки; не публикуйте подпись.
- **Широкие полномочия:** permits, ордера, ключи сеанса и операции смарт-аккаунта могут разрешать будущие действия без нового запроса. Проверьте актив, spender, получателя, сумму, охват и отмену.
- **Компрометация подписанта:** аппаратный кошелёк защищает от извлечения ключа, но не от вредоносного сообщения. При утечке seed-фразы или закрытого ключа считайте скомпрометированным весь аккаунт.

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

<a id="misconceptions"></a>

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

- **«Любая подпись перемещает средства».** Многие лишь аутентифицируют или выражают намерение; некоторые разрешают последующее перемещение.
- **«Без gas безопасно».** Ретранслятор может оплатить gas и отправить подписанный permit, ордер или иную авторизацию.
- **«EIP-712 гарантирует безопасность».** Он улучшает отображение и разделение доменов, но не защищает от повторов и не проверяет заявления приложения.
- **«Восстановленный адрес доказывает осознанное согласие».** Он связывает точные данные с ключом по правилу, но не доказывает личность, понимание или свободу воли.
- **«Подписи контрактных кошельков обычны».** Действительность ERC-1271 может зависеть от текущего состояния и политики; проверяющий должен вызвать контракт.

<a id="related"></a>

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

- [Типизированная подпись EIP-712](/ru/crypto/eip712-typed-signature/)
- [Разрешение кошелька](/ru/crypto/wallet-approval/)
- [Риск подписи Permit2](/ru/crypto/permit2-signature-risk/)
- [Симуляция транзакции](/ru/crypto/transaction-simulation/)
- [Фишинговое мошенничество](/ru/crypto/phishing-scam/)

<a id="sources"></a>

## Источники

- [ERC-191: Signed Data Standard](https://eips.ethereum.org/EIPS/eip-191) - Ethereum Improvement Proposals (дата доступа: 2026-08-22)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (дата доступа: 2026-08-22)
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (дата доступа: 2026-08-22)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (дата доступа: 2026-08-22)
- [ERC-4361: Sign-In with Ethereum](https://eips.ethereum.org/EIPS/eip-4361) - Ethereum Improvement Proposals (дата доступа: 2026-08-22)

Source: https://wiki.fcontext.com/ru/crypto/wallet-signature/index.mdx
