У смарт-кошелька нет одного приватного ключа, который можно восстановить из подписи обычным способом. Владельцами могут быть несколько адресов, правила могут требовать порог подписей, а проверка иногда зависит от конфигурации контракта. ERC-1271 задаёт интерфейс, через который приложение спрашивает сам контракт: считает ли он подпись действительной для данного хэша.
Для внешнего аккаунта приложение часто восстанавливает подписавший адрес. Для контрактного аккаунта оно должно обратиться к кошельку в нужной сети. Ни внешний вид подписи, ни её длина не сообщают, кто уполномочен действовать от имени такого кошелька.
Что стандартизирует ERC-1271
Стандарт определяет метод `isValidSignature(bytes32 hash, bytes signature)`. Кошелёк проверяет хэш и данные подписи по своей внутренней логике. При успехе он возвращает специальное четырёхбайтовое значение `0x1626ba7e`; другое значение или ошибка означают, что проверка не прошла ожидаемым образом.
ERC-1271 не предписывает один способ управления. Реализация может проверять одного владельца, порог нескольких, аппаратный ключ или составной формат. Поэтому приложение не должно декодировать любую подпись смарт-кошелька как обычную ECDSA. Конкретный формат зависит от контракта.
Как выглядит проверка
Сначала приложение формирует точный хэш сообщения, а не строку с похожим смыслом. Если используется EIP-712, в дайджест входят структурированные поля и домен, обычно привязанный к приложению, версии, сети и контракту. Сверить поля поможет материал о проверке EIP-712 подписи. Изменение сети или одного поля создаёт другой хэш.
Затем клиент определяет, является ли адрес смарт-контрактом в выбранной сети, и вызывает `isValidSignature` как чтение состояния. Совпадение с magic value подтверждает решение реализации в момент проверки. Клиенту важно показать содержание запроса, адрес кошелька и сеть. Непонятное сообщение остаётся опасным даже при технически успешной проверке.
Почему результат может измениться
Подпись контрактного кошелька не обязательно является неизменным доказательством. Владелец может быть удалён, порог изменён, модуль отключён, срок действия истечь, а логика обновиться. Стандарт допускает контекстную проверку, поэтому те же байты могут быть приняты сейчас и отклонены после изменения состояния.
Это важно для входа по кошельку, ордеров вне блокчейна и согласований, которые исполняются позже. Приложению нужно определить, когда именно требуется действительность: в момент входа, размещения или исполнения. Для одноразового разрешения добавляют nonce и срок на уровне сообщения или приложения. Нельзя приписывать эти свойства самому ERC-1271.
Чем контрактный адрес отличается от обычного
Для внешнего аккаунта обычно проверяют подпись криптографически, а для контракта нужны сеть, код и состояние. Адрес может быть известен, хотя контракт ещё не развёрнут, и тогда обычный вызов невозможен. Для этого случая предназначен связанный стандарт ERC-6492, описанный в статье о проверке подписи ещё не развёрнутого кошелька.
Не путайте подтверждение сообщения с подтверждением транзакции multisig. В первом случае контракт отвечает на хэш и подпись. Во втором участники согласуют конкретную операцию с собственными полями и политикой. Перед совместным подтверждением отдельно проверьте транзакцию Safe, чтобы понимать, что подписывает каждый владелец.
Что учитывать интегратору
Проверяйте контракт в правильной сети и передавайте ровно тот digest, который будет использован. Принимайте только ожидаемое значение, а revert, пустой ответ и ошибку RPC считайте неуспешной проверкой. Если разрешение нужно в другой сети, проверяйте его именно там либо явно фиксируйте правила межсетевого сценария.
Стандарт предполагает неизменяющую состояние проверку, обычно вызываемую статически. Не доверяйте произвольной подписи только потому, что адрес похож на известный кошелёк. Интеграционные проверки должны покрывать верную и неверную подписи, смену владельцев, истёкшие разрешения и временную недоступность RPC.
Как читать подтверждение безопасно
Главный вопрос не только «верна ли подпись», но и «что она разрешает». Проверьте домен, сеть, адрес приложения, сумму, актив, nonce, срок и назначение вызова. Даже сообщение для входа может содержать полномочия шире обычной авторизации, если интерфейс показывает его неясно.
ERC-1271 помогает приложениям работать с контрактными аккаунтами, но не является универсальным сертификатом безопасности. Он подтверждает решение конкретной логики относительно хэша в конкретном состоянии. Корректная интеграция сочетает соблюдение стандарта, понимание политики кошелька и понятное отображение запроса пользователю.
Почему одной проверки ответа недостаточно
Ожидаемый magic value подтверждает только результат функции для переданного хэша. Он не доказывает, что пользователь прочитал запрос или что приложение верно описало действие. Сайт может подставить другой адрес контракта, сеть или digest, а кошелёк подтвердит именно это значение. Интерфейс должен связывать технический результат с ясным отображением содержания подписи.
Надёжный клиент сверяет chain ID, signer и домен сообщения, ограничивает срок challenge и проверяет ответ через выбранный RPC. Если чтение недоступно, нельзя молча переключаться на иной способ подтверждения. Для восстановления доступа и нескольких владельцев могут применяться guardians; подробнее об этом рассказывает статья о social recovery кошелька.
Проверка на стороне сервиса
Сервису, который принимает подпись для входа, нужно связать challenge с конкретной сессией и ограничить его срок действия. После проверки отметьте nonce использованным, чтобы подпись нельзя было повторно применить для другого запроса. Это прикладные меры защиты от повторного использования, а не обязательные поля, которые ERC-1271 добавляет автоматически.
Проверяйте именно тот адрес, который пользователь выбрал в кошельке, и не принимайте ответ от похожего контракта в другой сети. Если провайдер чтения переключился на резервный endpoint, убедитесь, что он всё ещё обслуживает правильную цепочку. Эти проверки полезны и при входе через passkey, но подпись smart account всё равно должна обрабатываться по правилам контрактного аккаунта. Для сравнения альтернативного способа аутентификации есть отдельный разбор passkeys в криптокошельках.
