内容摘要与导读：
以太坊三种提案的取舍：8223 侧重“免 ETH 付 gas”，但本质仍是 EOA 加赞助合约；8202 更像签名算法升级，解决的是抗量子安全，不是真正的账户抽象；8141 则把验证、支付、批处理等能力做成协议原语，能覆盖会话密钥、社交恢复、限额、多签、WebAuthn 等真实 AA 需求。7702 之所以 adoption 不佳，是因为它只是原语不是产品，因此下一步不应更保守，而应直接推进更完整的 8141。
为什么 Ethereum 应该发布 EIP‑8141，而不是 8202 或 8223
EIP‑7702 已经上线一年多了。大多数主流钱包仍然没有以有意义的方式集成它。如今很多人得出的教训是“让未来的提案保持狭窄”。我认为这种解读完全错了。7702 采用率低，是因为它是一个 primitive，而不是一个产品。如果我们真心想推进 AA，下一步就应该更有雄心，而不是更保守。这意味着要发布 EIP‑8141。
三个提案一览
AA 到底意味着什么
Account abstraction 的核心主张是：某个 account 上一笔交易是否有效，其规则应当可以由 account 本身通过代码来定义。Session keys、social recovery、spending limits、multisig‑as‑root、任意 2FA：这些都是这一想法带来的结果。
8202 仅覆盖了一个用例，8223 覆盖了两个，而 8141 覆盖了全部。这不是修辞，而正是“abstract”的含义。
8223 是一个陷阱
“Users don't need ETH” 是一个具体的卖点，而且工程面也很小。我曾经认为 8223 是最有可能发布的提案。后来我改变了看法。
8223 提供的是 gas sponsorship，而不是 AA。用户仍然使用 ECDSA EOA 签名。payer contract 是 escrow，不是 validator。所有真正的 AA 功能，仍然只是那个 contract 里的 Solidity 脚手架，并且受 EOA 的 root signature 约束。你只是用不需要 bundlers 的方式重新实现了 4337，但并没有改变 authorization 的底层。
更糟的是：如果先发布 8223，就会把 EOA‑as‑signer 模式再固化十年。工具、indexer、审计、wallet UX 都会围绕“hot EOA + payer contract + 7702 delegation”锁定。等到两年后再提出 8141 时，房间里的反应会变成：“我们不是已经解决 sponsorship 了吗，为什么还需要 frames？”狭窄的提案不只是没能解决 AA，还会让以后更难解决它。
8202 很优雅，但它不是 AA
8202 是这三个提案里最优雅的。它与 1559 的差异最小，为 secp256k1 保留了 legacy addresses，并为 PQ safety 提供了一个巧妙的 Merkle‑tree ephemeral scheme。
但它不是一个 AA 提案，而是一个 signature‑scheme upgrade。发送者仍然是 EOA。有效性的判断仍然是“这个 key 有没有签名”。有效 scheme 的集合，仍然是一个由 protocol upgrades 控制的固定 registry，而不是一个由 account 自行定义的开放集合。
如果你的目标是 quantum safety，8202 是合适的载体。如果你的目标是 AA，8202 并没有推动任何真正重要、且用户可见的功能。它所有的工程成本只换来一件事：PQ signing。值得做，但不值得拿它来代替 AA。
8141 才是答案
8141 是唯一一个把 AA 作为其本应属于的 protocol‑level 问题来处理的提案。三个 frame mode（DEFAULT、VERIFY、SENDER），用于 frame introspection 的新 opcodes，一级 paymasters，以及带有每个 frame receipts 的原子 batching。
每一个 AA 功能，都可以变成 VERIFY frame 中的 Solidity。Social recovery：检查一个 multisig。Session keys：根据 storage 验证一个有时效限制的 sub‑key。Spending limits：读取一个按周期计数的计数器。BLS、passkey、WebAuthn：全都是 frames。只要 primitive 存在，这些每一个都只是一个周末项目。每一个也都是可以发布、可以营销的用户功能。
Paymasters 是原生的。ETH gas 可用，ERC‑20 gas 可用，协议资助的 gas 也可用。没有 alt‑mempool，也没有 bundler 中心化。
7702 的数据并不意味着人们以为的那样
常见的反对意见是：“7702 很复杂，而且采用率低，所以 8141 只会更糟。”不妨反过来想。7702 采用率低，是因为它是一个没有产品的 primitive。“你的 EOA 可以运行代码”是基础设施，不是功能。Wallet 很正确地看出，只发布 7702 本身并不会改善用户指标，因为每一个真正的功能都还需要在其之上继续发明。
8141 发布的是产品。tx type 里有 paymasters。tx type 里有 batching。tx type 里有 validation abstraction。7702 的数据并不能证明复杂 tx type 会失败。它真正证明的是：不完整的 tx type 会失败。8223 和 8202 都是不完整的。8141 才是把事情做完。
迁移现实
采用每个提案分别需要谁付出什么：
最显眼的一行是：8202 的 ephemeral scheme 是唯一一种既昂贵、又无法通过 7702 软化迁移成本的方案。其他所有路径都有一个 7702 形状的 cheat code，能够保留用户的地址和资产完整性。8202 下的 PQ safety 做不到这一点。
8141 的采用逻辑则是：一次集成就能解锁 session keys、recovery、batching、native paymasters、ERC‑20 gas、自定义有效性。“一次集成，六个可营销功能”的 ROI，会打破 7702 的模式，而不是重复它。
诉求
致正在决定这些提案谁先发布的核心开发者：请优先选择 8141。
优先发布最容易推理的提案，这种直觉我完全理解。8223 很小。8202 很优雅。它们都更容易在会议上辩护。我明白。但这些简单方案并不能把我们带到 AA。它们只会把我们带到一个更好的 EOA，而更好的 EOA 并不是过去十年 AA 研究的目标。8223 只是改变了 gas payer。8202 只是改变了签名算法。二者都没有改变 authorization floor。只有 8141 做到了。
VOPS compatibility 是可以解决的：validation access lists、pre‑execution witnesses，以及在 frame world 内部作为快速路径的 8223 registry pattern。mempool 的担忧属于细化问题，而不是阻塞问题。实现面确实很大，但那正是所有 AA 功能合并之后的总表面。另一种选择，则是在未来十年不断推出一个又一个狭窄提案，每个只解决 AA matrix 的一个单元格。那样总工作量会更大，分散给更多参与方，而且结果也更不连贯。
我更希望看到的版本是：把 8141 作为北极星。让 8223 的 registry predeploy 作为其中 canonical paymaster 的快速路径存在。让 8202 的 ephemeral scheme 作为 VERIFY frame 发布。狭窄提案不必消失。它们会成为完整 primitive 中那些照亮的路径，而不是它的替代品。那才是所有人都赢的版本。
致钱包工程师：请按 8141 即将到来的前提来做架构。把你的 account contracts 当作未来会在 protocol level 上表达为 VERIFY frames 的预迁移。
致周二早晨正在权衡取舍的核心开发者：我知道 8141 是更难的选择。但我还是要请求你们做出这个选择。这个决定将决定 Ethereum 的 account model 在十年后是否真的 abstract，还是说我们会花掉那十年，继续围绕一个本该在有机会时就移除的底线去构建。发布一个真正的 AA primitive 的窗口不会永远敞开。请抓住它。
原文链接：x.com/ch4r10t7r/status/...
了解更多以太坊开发资源，欢迎访问云栈社区（技术文档）。
发表于 5 小时前
|
查看: 3|
回复: 0
