EIP-155如何阻止跨链重放？ 图 1
EIP-155如何阻止跨链重放？ · 图 1

EIP-155把chainId写进旧式交易的签名哈希，并把它编码进v。它降低同一签名被拿到另一条链重放的机会，但只有签名器、节点和界面都使用正确chainId时才成立。

本文聚焦旧式交易的九字段哈希与v反解，不重复讲一般多链切换；类型化交易则只作为对照。

用chainId=1算出v

旧式受保护交易签名的哈希对象由六个原字段加上chainId, 0, 0组成。若chainId为1，恢复位为0或1，v分别是1 × 2 + 35 = 37或38；chainId为10时，对应55或56。收到v≥35的旧式交易，可先按floor((v-35)/2)得到候选chainId，再结合奇偶恢复签名位。

v能否从EIP-155推出网络处理
27/28不能这是未绑定chainId的旧式签名
37/38候选chainId=1仍需核对RPC网络
55/56候选chainId=10仍需核对目标合约与界面

反解只是检查交易声明；私链如果复用了同一chainId，密码学层仍无法替用户区分两个环境。

从输入到验收

阶段动作
准备从RPC读取eth_chainId并与用户选定网络独立比对
读取按交易类型选择legacy九字段或类型化payload，不能混算
解释重新编码待签名字节并显示chainId、to、value与data摘要
复核签名后从v或payload再次核对chainId
收尾广播前查询目标地址代码和nonce，防止界面网络与RPC网络不一致

事实与证据边界

核验项可确认结论
九字段签名哈希EIP-155保护的旧式交易在签名哈希中追加chainId、0、0，并把签名恢复位编码为chainId乘2再加35或36。
v值反解表v值为27或28的旧式签名没有按EIP-155绑定chainId；验证者不能从这类v值推出唯一目标网络。
旧式与类型化交易类型化交易由各自payload显式携带chainId，签名前仍要独立核对RPC网络、收款地址与合约，chainId本身不证明界面可信。

九字段签名哈希如何做双盲复核

作者先依照“从RPC读取eth_chainId并与用户选定网络独立比对”收集一份不含结论的证据包，内容包括目标对象、网络或版本、完整返回、查询时点和使用的工具。复核者收到材料后，按“按交易类型选择legacy九字段或类型化payload，不能混算”自行解释v值反解表。双方最后才交换结果；如果结论不同，优先比较原始字段与口径，不能用页面颜色或多数意见裁决。

接着建立反例包。反例一只模拟“把v=27/28强行反解成某条链，会制造不存在的安全结论”，反例二只模拟“只核对chainId，不核对同地址合约在两条链上的代码”。每个反例必须说明预期拒绝点和实际拒绝点。程序若把错误输入修正后继续执行，应把修正动作完整展示；静默修正会让用户误以为原输入有效，因此仍判为不通过。

为了覆盖网络核验清单，还要在状态改变前后各保存一次“重新编码待签名字节并显示chainId、to、value与data摘要”的结果。两份证据必须有独立时间和上下文，不能只留最终快照。若变化由缓存、节点或索引造成，报告应注明观察层级，而不是直接断言链上事实改变。

上线页面把原始证据、解释规则和结果状态拆开呈现。原始栏不做舍入和自然语言改写；解释栏写清公式、版本或字段映射；结果栏允许已确认、被否定和待核验。触发“把“防跨链重放”误写成“签名不可被业务重复使用””时，按“签名后从v或payload再次核对chainId”重新取证，禁止继续自动处理。

三个容易造成错误结论的做法

  • 不要这样做：把v=27/28强行反解成某条链，会制造不存在的安全结论
  • 不要这样做：只核对chainId，不核对同地址合约在两条链上的代码
  • 不要这样做：把“防跨链重放”误写成“签名不可被业务重复使用”

来源、增量与风险边界

  1. Ethereum Improvement Proposals：正式接口、字段与规范语义。
  2. EIP-2718：实现路径、兼容性或安全边界。

本文资料读取于2026-07-20。私链与兼容链可能配置相同或错误的chainId，跨链防重放还依赖部署方和签名界面正确使用该字段。

站内相邻主题可继续阅读：多链chainId核验、签名核对。chainId不是品牌身份，也不证明RPC可信。签名界面若隐藏目标合约、金额或data，用户应停止签名。