想解决的问题
以太坊的两类账户各有各的镣铐：外部账户（普通钱包地址）只能由私钥签名驱动，一次只能干一件事，付 Gas 必须持有 ETH；合约账户能批量操作、能收代付，却没有私钥，不能被用户直接拥有。2020 年 10 月提交的 EIP-3074 想给两者架桥：让普通账户用一个签名授权某个合约，此后合约可以以这个账户的身份执行调用。钱包用户第一次不需要先兑换 Gas 代币也能触发复杂合约流程，多步操作可以打包成一笔，这些是它最初吸引开发者的地方。
AUTH 和 AUTHCALL 怎么配合
方案落地成两条指令。EIP-3074 定义 AUTH：合约调用它时传入一个由用户签名保护的上下文承诺，验证通过后 EVM 把当前调用上下文的发起者换成签名者；接着合约用 AUTHCALL 以这个被接管的身份发起后续调用——转账、授权、进池子，每一步在别人看来都出自签名者本人。整个过程没有新增账户类型，实现很轻，一度进入过核心客户端的实现分支和测试网演练。
为什么最终被放弃
按 EIPs 仓库的记录，EIP-3074 的状态停在 Withdrawn（已撤回），撤回原因栏写明由 EIP-7702 取代。社区反对的要点可以归纳为两类风险。一类是权限形状：AUTH 验证签名后，合约接下来的 AUTHCALL 可以是任意目标、任意调用数据，用户的一纸授权在恶意合约手里等于把资产处置权整体移交——钓鱼网站诱导签一次名，钱包里的资产可被一次性搬空，这种全有全无的授权模型被认为过于锋利。另一类是签名上下文：为了防重放，签名内容里编码了调用者地址与承诺值，但这套机制让同一个签名工具在不同场景下的可复用边界变得微妙，安全研究者担心跨场景的签名误认。加上社区同时已有 ERC-4337 这条不改动 EVM 执行规则的账户抽象路线，两条方案在目标上重叠，资源与注意力集中到了后者与后来的 EIP-7702 上。
后来的 EIP-7702 改了什么
EIP-7702 的做法可以概括为把临时接管换成登记制度：用户签名声明在一段时期内、给自己的地址挂上指定合约的代码，期间这个地址的行为像合约一样可批量、可委托，但签名本身不授权任何即时操作，授权对象、有效期和 nonce 边界都写在链上可查可撤销。对比之下，EIP-3074 的签名是一次性的行动委托，EIP-7702 的签名是一段时期的身份加装——攻击面从那一瞬间的调用数据，变成了可见、可审计的委托记录。这也是它被选为替代方案的关键逻辑。
从一次性签名到可查账本
把两种设计的差异放进治理视角会更清楚：EIP-3074 的授权发生在链下签名里，事后只能从交易痕迹反推用户被授权合约做了什么；EIP-7702 的委托写在链上，谁在何时给地址挂了什么代码、 nonce 到哪个区间有效，浏览器上一目了然。授权从瞬时事件变成登记记录，用户维权、安全机构分析攻击路径都有了抓手，这比多一层技术防御更能改变行业博弈，也是方案取舍中最有分量的一条理由。
快速问答
问：EIP-3074 是否曾经在主网生效？ 答：从未。它停留在核心客户端的实现与测试阶段，最终在正式进入主网激活前被撤回。
问：撤回了还能被重新提起吗？ 答：Withdrawn 是文档层面的状态，理论上可重提，但当前路线已收敛到 EIP-7702 与 ERC-4337。
问：普通用户会碰到残留风险吗？ 答：要警惕仍冒用旧概念话术的签名请求，任何要求签名为某合约授权行动的弹窗都应先核实合约。
常见误区
一是把撤回归因于技术失败，更准确的说法是被更安全形态的方案取代；二是把 AUTHCALL 等同于 ERC-4337，前者改执行层语义、后者在协议外加验证层；三是以为钱包地址装上代码后私钥作废，账户的签名能力始终保留，这是它与创建合约账户的本质区别。
风险提示：本文为协议演进科普，不构成任何投资建议；处理钱包签名请求前请逐项核对授权内容与合约地址。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。