合约地址对不上？CREATE2 确定性部署与同地址不同代码

同一个项目方的合约，在以太坊主网和某条二级链上尾号一样，看起来像同一份代码。这种“一样”多半来自 CREATE2，它既可能帮你提前核对合约，也可能给你错误的安心感。本文讲清公式与两种误读。

普通地址为什么不可预测

默认的 CREATE 创建合约时，新地址由部署者地址加其当时随机数（nonce）的哈希决定。同一个地址每次部署地址都会变，部署前没人能精确预知落点，也谈不上跨环境对齐。

CREATE2 的公式

EIP-1014 引入的 CREATE2 把地址改为由固定输入决定：地址等于对 0xff、20 字节部署者地址、32 字节盐（salt）、初始化代码哈希拼接后再做 keccak256，取结果最后 20 字节。哈希前像固定 85 字节长。只要这组输入确定，地址在部署之前就能被任何人事前算出——“还没部署，地址已知”是这条标准最直观的特征。开头的 0xff 保证这类地址不会与普通 CREATE 地址碰撞。该操作码随 2019 年的君士坦丁堡升级进入以太坊主网。

对持有者有什么用

两个实际用途。其一，项目公告若给出部署参数，你可以自己计算部署地址，部署后与浏览器里的地址比对，确认上线的就是公告那一份。其二，不少团队用相同的工厂合约、按规则推导的盐部署多链版本，此时相同地址是一个值得进一步比对字节码的信号。

误读一：同地址不等于同代码

两个人完全可以选不同输入，在某条链上部署出语义上“看起来是同一个”的合约；同一份合约在不同链上若编译产物或初始化参数不同，地址也会不同。地址相同要么是巧合、要么是精心安排的巧合，代码是否相同要靠比对已验证字节码判断，不能靠地址脸熟。

误读二：地址会被抢跑吗

EIP-1014 自己指出：如果目标地址已有非零随机数或非空代码，再次创建会直接失败，该行为由 EIP-684 规定。也就是说，已落地的地址不会被别人的 CREATE2 顶掉。真正的风险不在协议层碰撞，而在你拿到的“预期地址”来自伪造公告——核对公告来源与计算参数，比信任任何人贴出的地址重要。

小结

CREATE2 把“合约在哪里”变成可计算的公开事实，用好了是一道免费的验证工具。建议的核对顺序：官方渠道取参数、自行算地址、部署后查字节码验证状态，三步都过再认定合约身份。

工厂与代理模式里的延伸用法

CREATE2 还支撑了一类你间接用过的结构：工厂合约按参数派生新地址（去中心化交易所的每个交易对地址、批量部署工具的每一个实例地址），以及给每个用户派生专属地址的钱包方案。识别这类场景的意义在于：看到地址规律一致的一组合约，可以推测它们出自同一工厂与同一份代码，再抽查其中一两个做源码验证即可，不必逐个核对，效率与安全兼得。 顺带一提，普通 CREATE 的地址依赖部署者随机数，因此同一地址的部署顺序决定了地址序列，重置账户或换地址部署都会打乱预期；而 CREATE2 完全绕开随机数，同一参数重复部署会因目标地址已有代码而失败，重复执行是安全的幂等失败，这让自动化工具敢于放心重试，不必担心地址漂移。

风险提示：本文仅介绍以太坊部署机制，不构成任何投资建议。任何地址与合约交互前请通过官方渠道交叉核验。