签名和序号不必只有一种写法：EIP-86 为账户抽象画的第一张草图

账户安全在当年是不可商量的默认值

2017 年初，以太坊上保护一个账户的方式只有一种：交易必须带上发送者私钥产生的 ECDSA 签名，并且携带一个从 0 开始逐笔递增的序列号。节点收到交易后验签名、对序列号，两关都过才执行。这套规则硬编码在交易处理流程里，谁也不能改。维塔利克在 2017 年 2 月 10 日提交的 EIP-86 想做的，就是把签名验证和序列号检查从协议里”抽象出去”，让账户合约按自己的逻辑决定怎么认定一笔交易合法。提案状态至今是 Stagnant（停滞），从未进入任何主网分叉，但它埋下的两个零件，二十年后仍能在链上找到回声。

一个不可能被签出来的签名值

把老地址直接升级成智能钱包：EIP-7377 迁移交易的一次性设计 之外，我们更熟悉的是钱包如何替你签名，而 EIP-86 的机制核心恰恰相反：先定义一种永远不来自任何私钥的签名。提案规定，如果一笔交易的签名字段是三元组 (CHAIN_ID, 0, 0)——r 和 s 为 0，v 取链号（主网为 1，与 EIP-155 用的数字一致）——节点就把它当作合法签名，并把发送者地址认定为 NULL_SENDER，即 2 的 160 次方减 1 这个全 F 的特殊地址。真实私钥几乎不可能碰巧产出这样一组签名值，于是协议给了账户合约一个没有天然主人的入口：谁声称代表这个地址，由账户合约自己检查。配套约束也很严：这类交易的手续费、序列号、转账金额必须全为 0，也不推进 NULL_SENDER 的序列号，防止这个特殊通道本身被滥用。

顺手留下的部署零件

EIP-86 还捎带提了两件与账户抽象并行的事。其一是名为 CREATE2 的新操作码，放在 0xfb，部署地址改由 sha3(sender + salt + sha3(init code)) 计算——用一段固定的初始化代码和一个盐值，先算出合约将来一定落在哪个地址。其二是部署碰撞规则：目标地址如果已经有非空代码或非零序列号，部署直接失败；只有空代码、空序列号但有钱的账户允许被部署覆盖。前者当年的公式与后来 EIP-1014 定稿的带 0xff 前缀版本并不相同，真正落地的是 1014 在 2018 年确定的形态；后者的精神则由独立提案固化为正式规则。也就是说，一个停滞提案里的两个零件，以修订后的样子活了下来。

为什么它自己停在半路

这条抽象路线没有被原样实施，原因可以列几条：把签名检查整体搬进合约，意味着验证逻辑出错时没有协议层兜底；协议还得先解决”合约替用户付手续费”的问题，这在当时没有可行答案；而且一个全 F 的特殊发送者给所有客户端和工具链都制造了新边界情况。后来这条线换了活法——先由智能账户类方案在协议之上搭账户合约，再逐步把验证逻辑标准化。对研究史来说，EIP-86 的位置是第一次把”账户安全可以是软件”写进正式文档。

普通用户从哪里感知这段历史

今天你如果用过 智能账户是什么？钱包风险，享受过免 Gas 费、社交恢复、多签策略这些能力，本质上都在受益于”检查逻辑可以是一段合约”这个观念。区别在于，当今方案不再靠协议级的特殊签名值，而是用专门的交易类型和入口合约来承接验证。用户需要记住的边界没有变：普通外部账户的钥匙就是你那一份私钥，丢了没有合约能替你找回；智能账户的恢复规则写在部署时选好的合约里，规则本身成了你新的”钥匙”。两种模型没有绝对优劣，但要清楚自己资产落在哪一边。

怎么确认自己用的账户属于哪一类

拿不准时可以做一次简单核对：看你的钱包应用是否要求你先”激活”或”升级”账户、是否有其他地址替你提交过一笔设置交易、恢复选项里是否写着监护人或恢复地址。这些都是账户合约存在的迹象。反过来，如果钱包直接问你助记词派生出的那个地址，且所有交易都由该地址直接发出，那你用的仍是协议默认规则保护的普通账户。两种账户在区块浏览器里的交易形态也不同：前者常见一条入口合约调用记录，后面才跟着真正的执行，这也是把它们区分开的最直接证据。