Сначала восстановите точный запрос

Digest — 32-byte хеш, который контракт получает аргументом, а signature — произвольный bytes-формат, понятный именно этому аккаунту. Не хешируйте читаемый текст повторно и не заменяйте digest тем, что показал интерфейс. Для typed data сохраните domain, types и message: руководство о том, что именно подписывает кошелёк, помогает восстановить исходный intent, но финальный объект проверки здесь — уже вычисленный digest.

Минимальный пакет воспроизводимости
ПолеЧто сохранитьПочему это граница результата
DigestРовно 32 bytes и правило его полученияДругой prefix/domain даёт другой запрос
SignatureПолный bytestring без нормализацииКонтракт сам определяет схему
SignerАдрес smart accountERC-1271 вызывают на нём, не на предполагаемом owner
Chainchain ID и RPC genesis/сетьКонтрфактический адрес и replay context могут различаться
Stateblock number/hashКод, owners, threshold и модули могли измениться
Минимальный пакет воспроизводимости
Поле
Digest
Что сохранить
Ровно 32 bytes и правило его получения
Почему это граница результата
Другой prefix/domain даёт другой запрос
Поле
Signature
Что сохранить
Полный bytestring без нормализации
Почему это граница результата
Контракт сам определяет схему
Поле
Signer
Что сохранить
Адрес smart account
Почему это граница результата
ERC-1271 вызывают на нём, не на предполагаемом owner
Поле
Chain
Что сохранить
chain ID и RPC genesis/сеть
Почему это граница результата
Контрфактический адрес и replay context могут различаться
Поле
State
Что сохранить
block number/hash
Почему это граница результата
Код, owners, threshold и модули могли измениться

Развёрнутый signer: проверка ERC-1271

Получите code signer через eth_getCode в том же block context. Если code есть, выполните eth_call к isValidSignature(bytes32,bytes) с точными digest и signature. Положительный результат — декодированный bytes4 0x1626ba7e. Revert, пустой ответ, другой bytes4 или RPC-ошибка не превращаются автоматически в универсальное «подпись поддельная»: сначала отделите отрицательный ответ контракта от недоступного historical state, неверного ABI и неправильной сети. Если RPC-узел не хранит нужный блок, результат пока unknown.

ERC-1271 разрешает контракту применять собственную схему: multisig threshold, session key, срок, nonce, owner registry или внешний вызов. Поэтому успешный ответ доказывает только то, что этот контракт признал эту пару hash/signature действительной в выбранном состоянии. Он не доказывает личность человека, бессрочную валидность, намерение выполнить транзакцию или успех UserOperation ERC-4337.

ERC-6492 проверяйте раньше code и ecrecover

Контрфактический smart account — заранее вычисленный адрес контракта, который ещё не развёрнут. ERC-6492 wrapper заканчивается обязательным 32-byte magic suffix 0x64926492 64926492 64926492 64926492 64926492 64926492 64926492 64926492, записанным без пробелов; до suffix ABI-кодированы factory/prepare target, calldata и original ERC-1271 signature. Детектор wrapper должен сработать первым — даже если по адресу уже появился code. Затем verifier симулирует factory или prepare call и вызывает isValidSignature с внутренней подписью.

Decision tool
НаблюдениеВеткаРезультат
Есть ERC-6492 suffixWrapper-first: decode → simulate factory/prepare → ERC-1271Valid / invalid / unknown с сохранённым revert
Suffix нет, signer имеет codeПрямой ERC-1271 eth_callТолько magic value означает valid
Suffix нет, code отсутствуетEOA/ecrecover — отдельная веткаНе выдавать её за ERC-1271
Исторический block недоступенArchive-capable RPC или другой узелUnknown, не invalid
Результат изменился между блокамиСравнить code/storage/owners и wrapper prepare pathОба результата могут быть корректны для своих состояний
Decision tool
Наблюдение
Есть ERC-6492 suffix
Ветка
Wrapper-first: decode → simulate factory/prepare → ERC-1271
Результат
Valid / invalid / unknown с сохранённым revert
Наблюдение
Suffix нет, signer имеет code
Ветка
Прямой ERC-1271 eth_call
Результат
Только magic value означает valid
Наблюдение
Suffix нет, code отсутствует
Ветка
EOA/ecrecover — отдельная ветка
Результат
Не выдавать её за ERC-1271
Наблюдение
Исторический block недоступен
Ветка
Archive-capable RPC или другой узел
Результат
Unknown, не invalid
Наблюдение
Результат изменился между блоками
Ветка
Сравнить code/storage/owners и wrapper prepare path
Результат
Оба результата могут быть корректны для своих состояний

Runbook без изменения состояния

  1. 1
    Заморозьте входы

    Запишите digest, signature, signer, chain ID и block hash/number; сохраните raw RPC requests/responses.

  2. 2
    Проверьте wrapper

    Сначала сравните последние 32 bytes с полным ERC-6492 suffix из блока выше — восемь групп 64926492 без разделителей — и, если он совпал, декодируйте три внутренних поля.

  3. 3
    Зафиксируйте code

    Вызовите eth_getCode на выбранном блоке; latest без block hash не воспроизводит историческую проверку.

  4. 4
    Выполните правильную ветку

    Для deployed account — прямой ERC-1271; для wrapper — side-effect-free universal validation.

  5. 5
    Сохраните точный outcome

    Отделите magic value, другой return, revert и transport/provider error.

  6. 6
    Повторите независимо

    При споре используйте второй RPC с тем же chain и block; не меняйте digest или bytes подписи между попытками.

Stop-сигналы

  • verifier применяет ecrecover до проверки ERC-6492 suffix и contract code;
  • адрес owner подменяют адресом signer smart account;
  • проверка идёт на latest, хотя спор относится к историческому блоку;
  • factoryCalldata предлагают broadcast без декодирования и симуляции;
  • валидность обещают навсегда, несмотря на upgrade или смену owners/threshold;
  • для диагностики просят seed или private key — они не нужны для публичной проверки.

Recovery завершён, когда сохранён воспроизводимый verdict для одной пятёрки digest/signature/signer/chain/block и понятен слой отказа. Если результат unknown, запросите archive state, правильный ABI или точную factory-версию; если invalid — заново получите подпись над тем же intent после проверки domain и актуальных полномочий. Не превращайте смену блока, сети или digest в «повторную проверку» того же доказательства.

Источники

Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.

  1. ERC-1271 — Standard Signature Validation Method for Contracts Ethereum Improvement Proposals · Проверено 24 августа 2026 г. в 09:25 GMT+5
  2. ERC-6492 — suffix 0x6492649264926492649264926492649264926492649264926492649264926492 Ethereum Improvement Proposals · Проверено 24 августа 2026 г. в 09:25 GMT+5
  3. Ethereum JSON-RPC — state methods and block parameter ethereum.org · Проверено 24 августа 2026 г. в 09:25 GMT+5
  4. EIP-712 — typed structured data hashing and signing Ethereum Improvement Proposals · Проверено 24 августа 2026 г. в 09:25 GMT+5
Материал носит информационный характер и не является индивидуальной рекомендацией. Криптоактивы связаны с риском волатильности, технических сбоев, хищения и полной потери средств.