Смарт-кошелёк может иметь вычисленный адрес до появления кода в блокчейне. Аккаунт можно подготовить заранее и иногда подписывать сообщения до первой транзакции, но обычная проверка не сработает: по адресу пока нельзя вызвать `isValidSignature`. ERC-6492 определяет способ передать данные, необходимые для такой проверки.
Формат расширяет ERC-1271, а не отменяет его. Если контракт уже развёрнут, приложение проверяет контрактную подпись обычным способом. Если кошелёк ещё counterfactual, подпись может содержать вызов фабрики для подготовки контракта. Базовую модель можно прочитать в материале об ERC-1271 и смарт-кошельках.
Зачем нужен стандарт
Кошелёк с предсказуемым адресом может быть создан заранее, но развёрнут только при первой транзакции. Приложению может понадобиться принять его подпись для входа, заявки или подтверждения права. На пустом адресе кода нет, поэтому стандартный вызов ERC-1271 невозможен. Проверять такую подпись как обычную EOA тоже неверно: адрес контракта не обязан соответствовать одному внешнему ключу.
ERC-6492 задаёт wrapper с данными фабрики, calldata создания или подготовки и исходной подписью для ERC-1271. Формат распознаётся по специальному 32-байтовому суффиксу, magic bytes. Он указывает тип подписи, но сам по себе не доказывает её подлинность. Проверяющая сторона всё равно должна установить, подходит ли подпись ожидаемому адресу и сети.
Последовательность проверки
Сначала проверяется наличие суффикса ERC-6492. Если он есть, wrapper декодируется, выполняется предусмотренная подготовка аккаунта и исходная подпись проверяется через ERC-1271. Если wrapper отсутствует, контракт с кодом проверяется непосредственно через ERC-1271. Обычная ECDSA-проверка относится к сценарию внешнего аккаунта, для которого контрактная проверка не применима.
Порядок принципиален: ERC-6492 должен распознаваться до стандартной проверки ERC-1271 и до `ecrecover`. Иначе wrapper можно ошибочно истолковать как подпись другого типа. Если адрес уже развёрнут, актуальная логика контракта имеет значение; описанный стандартом шаг подготовки также позволяет обработать контракт, которому нужно завершить инициализацию для проверки.
Что означает factory-вызов
Проверка сложнее обычного чтения: factory-вызов может развернуть контракт, изменить состояние или обратиться к другим контрактам. Для offchain-сценария обычно используют `eth_call` с валидатором, который симулирует последовательность без записи изменений в блокчейн. Эталонная реализация EIP предусматривает возврат результата так, чтобы побочные эффекты проверки не сохранялись.
При onchain-проверке разработчику нужно продумать побочные эффекты, повторный вход, стоимость газа и намеренные revert. Нельзя исполнять произвольный вызов из подписи в контексте приложения, не понимая, какие контракты будут вызваны. Обёртка улучшает совместимость, но не превращает factory calldata в безопасный код.
Проверки для пользователя и приложения
Пользователь должен сверить сеть, ожидаемый адрес кошелька и смысл подписанного сообщения. Проверьте домен приложения, nonce, срок, права и актив, если подпись относится к средствам. Хэш должен быть рассчитан по точным данным. Для структурированного EIP-712 запроса сверьте поля по инструкции проверки подписи EIP-712.
Разработчику нужен совместимый валидатор и надёжное декодирование wrapper. Убедитесь, что результат подготовки соответствует адресу подписанта и что сеть совпадает с контекстом фабрики. Тестируйте неверный суффикс, неправильную ABI-кодировку, неожиданный адрес фабрики, revert, неверный magic value ERC-1271 и обычную подпись внешнего аккаунта.
Связь с CREATE2 и адресом
EIP рекомендует использовать ERC-6492 с CREATE2, позволяющим предсказать будущий адрес. Но проверяющая сторона не должна просто доверять фабрике и calldata из wrapper. Нужно подтвердить связь между ожидаемым адресом подписанта и результатом подготовки, а также проверить сеть, фабрику, параметры создания и конфигурацию владельцев.
Реализации используют разные фабрики и способы инициализации. Если адрес не совпадает с ожидаемым smart account пользователя, валидная подпись другого контракта не является подтверждением. Проверка привязывается одновременно к signer, digest и сети, а не только к успешному выполнению factory-вызова.
Риски и ограничения
Подпись может проверяться иначе после развёртывания аккаунта. Если код уже существует, нужно учитывать актуальные ключи, модули и настройки. Владелец может измениться, модуль отключиться или подпись стать недействительной. Успешная проверка в один момент не обязательно даёт бессрочное разрешение.
Нельзя смешивать offchain `eth_call` с развёртыванием кошелька в основной сети. Симуляция не является пользовательской транзакцией, но отдельный onchain вызов способен менять состояние и требовать gas. Для Safe отдельно читайте поля операции по инструкции проверки транзакции Safe, а модель порогового кошелька описана в материале о создании Safe multisig.
Что проверить перед принятием подписи
Подтвердите используемую версию стандарта, порядок проверки суффикса, формат данных и обработку ошибок. Проверьте, что offchain-симуляция не оставляет изменений, если ожидалось чтение, а фабричные вызовы ограничены известными контрактами. Для важной операции используйте актуальное состояние сети и повторяйте проверку перед исполнением.
ERC-6492 решает задачу проверки подписи до появления кода кошелька в блокчейне. Он не отменяет проверку сообщения, signer, сети, фабрики и прав доступа. Надёжная интеграция сочетает точное соблюдение стандарта, защиту от побочных эффектов и ясное отображение запроса пользователю.
