ERC-191签名消息前缀怎么读？ 图 1
ERC-191签名消息前缀怎么读？ · 图 1

ERC-191先用0x19阻止签名数据被直接解释成合法RLP交易，再用一个版本字节选择不同消息信封。读取签名时必须先还原“实际签了哪些字节”，不能从钱包弹窗的自然语言倒推。

本文回答0x00、0x01和0x45三种版本如何分流，并强调密码学有效与业务授权是两件事。

三个必须保留的事实

  1. 版本字节表：ERC-191签名数据以0x19开头，随后是单字节版本、版本专用数据和实际消息，使其不能直接成为一笔合法RLP交易。
  2. 三种消息信封：版本0x00用于绑定预期验证者，0x01对应EIP-712结构化数据，0x45对应Ethereum Signed Message个人签名格式。
  3. 签名验证流程：密码学验证成功只证明某个密钥签过这些字节，不证明钱包完整展示了消息、操作目的或授权后果。

操作前后逐项勾选

  • 确认调用方使用personal_sign、typed data还是自定义ERC-191封装
  • 从原始请求重建完整字节，包含长度、domain或预期验证者
  • 用声明账户恢复签名地址，并核对合约钱包是否走ERC-1271
  • 检查nonce、deadline、用途和消费状态是否由业务验证
  • 把验证结果拆成“签名有效”“上下文匹配”“授权仍可用”三项

三种常见字节布局

版本拼接骨架典型用途
0x000x19 00 + intended validator + data把消息绑定到预期验证合约
0x010x19 01 + domainSeparator + hashStructEIP-712结构化数据
0x450x19 45 + “thereum Signed Message”前缀 + 长度 + messagepersonal_sign消息

0x45看起来少了字母E，是因为0x45本身就是ASCII的E。验证服务应保存版本、版本专用数据和消息原文，然后用相同字节重算哈希。若应用在0x00数据里没有加入链、nonce或期限，前缀本身不会自动补齐这些业务约束。

故障与停止条件

误判正确处置
只验证恢复地址，不展示实际消息字节保留原始证据，停止外推并按本文步骤复核
把0x19前缀当成防重放机制，省略一次性nonce保留原始证据，停止外推并按本文步骤复核
把结构化数据中的name或logo当成合约身份保留原始证据，停止外推并按本文步骤复核

四问复评签名验证流程

输入是否能被别人重放？

用已知对象执行“确认调用方使用personal_sign、typed data还是自定义ERC-191封装”，保存所有必需字段，而不是截图。第二个人根据版本字节表重建同一请求或字节，再做“从原始请求重建完整字节，包含长度、domain或预期验证者”。如果缺少网络、版本、区块、账户或时间上下文，即使数值相同也不能算复现。

错误是否真的被拦住？

先只注入“只验证恢复地址，不展示实际消息字节”，记录预期错误与实际返回；恢复成功样本后，再单独注入“把0x19前缀当成防重放机制，省略一次性nonce”。错误处理不得使用旧缓存冒充新结果，也不能把null、未知类型或权限失败自动改成零值。每个反例只变一个条件，才能定位校验是否生效。

状态变化后旧结论会不会残留？

围绕业务授权边界制造一次可控变化，并在变化前后分别执行“用声明账户恢复签名地址，并核对合约钱包是否走ERC-1271”。页面同时展示两份证据的对象、上下文和时间；新状态不能覆盖审计历史，旧状态也不能继续显示为当前完成。

什么时候停止自动流程？

一旦出现“把结构化数据中的name或logo当成合约身份”，状态转为待核验，并要求人工执行“检查nonce、deadline、用途和消费状态是否由业务验证”。交接时把版本字节表原文、三种消息信封推导和签名验证流程验收分栏保存，使复核者能判断问题来自规范理解、现场环境还是展示逻辑。

来源、增量与风险边界

来源本文用途
Ethereum Improvement Proposals正式接口、字段与规范语义
EIP-712实现路径、兼容性或安全边界

本文资料读取于2026-07-20。应用自定义消息仍可能省略链、合约、nonce或截止时间；不能因使用ERC-191前缀就自动判断不可重放。

站内相邻主题可继续阅读：EIP-712签名核对、合约签名验证。签名有效只说明密钥签过指定字节，不等于同意界面描述的后果。缺少用途、期限或验证者绑定时应拒绝高风险操作。