从第一性原理理解账户抽象
如果你曾在 Ethereum 上使用过自托管钱包，那么无论你是否意识到，你都用过外部拥有账户——也就是 EOA。账户抽象的讨论，要从理解 EOA 是什么开始：为什么它的设计限制了你在链上能做的一切，以及 ERC-4337 账户抽象如何在不触及基础协议的前提下绕过这些限制。本文是一个系列的入口，它将带你从最初的限制，一路讲到 SSP 如何利用账户抽象在 EVM 链上运行其 2-of-2 multisig。
这是奠基性的概念篇章。如果想专门了解 ERC-4337 标准本身，请把什么是账户抽象（ERC-4337）？与本文搭配阅读——在这里，我们建立的是为什么需要这个标准的直觉。
Ethereum 给你的那种账户
Ethereum 有两类账户。合约账户由代码治理。EOA——大多数人使用的普通钱包——由一把私钥治理。持有那把私钥的人可以授权该账户的任何交易，而协议只验证一件事：交易携带一个在 secp256k1 曲线上有效的 ECDSA 签名，且该签名由控制该地址的私钥生成。
这条唯一的规则很优雅，同时也是下文每一项限制的根源。一笔交易是否有效，被硬编码进了协议。作为账户所有者的你，无权决定"有效"意味着什么。是协议来决定，而它只会检查一把私钥的一种签名方案。
这种设计从根本上带来了什么
四项限制直接源于"一把私钥、一个签名"的模型：
- 一把私钥即单点故障。 丢了私钥，资金就没了。泄露了私钥，攻击者就拥有了一切。协议层面没有第二因素，没有共同签名者，也没有任何本可以阻止盗窃的策略。
- 没有自定义验证逻辑。 EOA 无法表达"要求两个签名"，也无法表达"自动允许这笔小额支付，但超过某个阈值就要求额外批准"，更无法表达"让这把私钥只在工作日花费"。账户没有逻辑，它只有一道签名检查。
- 发送方必须持有 ETH 来支付 gas。 每笔 EOA 交易都用 ETH 支付自己的 gas。一个只持有 ERC-20 代币却没有 ETH 的新用户无法动用那个代币，因为他付不起手续费。手续费支付方与交易发送方被迫是同一个账户。
- 助记词的使用体验毫不留情。 因为私钥就是账户，开通就意味着抄下一组助记词并永远保护它。没有任何一条恢复路径能绕开这组助记词，而一次失误就是永久的。
这些都不是缺陷，而是验证逻辑驻留在协议中、而非账户中所带来的后果。
核心理念：让账户可编程
账户抽象的理念，就是把那套验证逻辑从协议中搬出来，放进账户本身。与其让网络硬编码"一笔交易若带有一个正确的 ECDSA 签名即有效"，不如让一个 smart account——一个保管你资金的合约——自行决定什么算是有效交易。
一旦账户成为可编程的合约，那四项限制就化为了设计选择：
- 它可以要求两个签名而非一个，这正是 multisig 在没有协议原生支持的情况下得以实现的方式。
- 它可以实现恢复规则，于是丢失一把私钥不再是故事的终点。
- 它可以让别人来支付 gas，把手续费支付方与发送方分离开。
- 它可以把若干动作打包——比如授权与兑换——合并为一次原子操作。
账户不再是一个被动的密钥对，而成为由你掌控的可编程逻辑。
ERC-4337 如何在不进行硬分叉的情况下实现这一点
难点在于：改变 Ethereum 验证交易的方式，通常意味着改动基础协议——那是一次缓慢、充满争议、波及全网的升级。ERC-4337 完全绕开了这一点。它把账户抽象作为一个凌驾于现有网络之上的层来引入，无需任何共识层面的改动。
该机制依托于几个部件：
- UserOperations。 smart account 不再发送一笔普通交易，而是把意图表达为一个
UserOperation——一个结构化对象，描述账户想做什么、以及应如何被验证。 - 一条替代性 mempool。 UserOperations 存活于它们自己的 mempool 中，与常规交易相分离。
- Bundlers。 一个 bundler 从那条 mempool 收集 UserOperations，把它们打包在一起，作为一笔真实交易提交上链，并支付基础层的 gas。
- EntryPoint 合约。 唯一一个经过审计的
EntryPoint合约是链上的咽喉要道。它调用每个 smart account 以运行该账户自己的验证逻辑，验证通过后再执行该操作。 - Paymasters。 一个可选的
paymaster合约可以同意为某个 UserOperation 承担 gas，这正是无 gas 流程与代币付费流程得以实现的原因。
合在一起，这让任何合约都能充当一个完全可编程的账户，由它自己的规则来验证，而底层的 Ethereum 协议则原封不动。该标准在 EIP-4337 中作了规范，Ethereum 自己的账户抽象路线图则追踪着这项更宏大的工作正走向何方。
为什么这对自托管用户很重要
对于自己保管私钥的人来说，账户抽象并不是一个抽象的协议细节——它改变了钱包能够安全做到的事：
- 无需原生支持的 multisig。 一个 smart account 可以要求不止一个签名，因此钱包可以要求两台独立设备批准每一笔转账。这正是 SSP 所依赖的基石，更详细的说明见以账户抽象方式实现的 EVM Multisig。
- 恢复选项。 可编程的验证为各种恢复流程打开了大门，使其不再坍缩成一组单一而脆弱的助记词。
- Gas 代付。 paymasters 意味着手续费可以与发送方解耦，抹平开通过程中最糟糕的摩擦。
- 打包。 多个步骤可以作为一次操作来结算，既减少点击，也降低中途失败的风险。
单把私钥的 EOA 与可编程的 smart account 之间的实际差异，大到足以值得专门论述——参见 EOA 与 smart account：真正重要的区别。
SSP 在其中的位置
SSP 是一款围绕 2-of-2 multisig 构建的自托管钱包。一把私钥存放在 SSP Wallet 浏览器扩展中；第二把存放在 SSP Key 手机应用中。每笔交易都在扩展中构建、在手机上共同签名，因此单凭任何一台设备都无法动用资金。
在 EVM 链上，SSP 借助 ERC-4337 来实现这种 2-of-2。该钱包是一个 ERC-4337 smart account，其验证逻辑要求两把私钥同时参与，而两个部分签名会——以 MuSig2 风格、在 secp256k1 上——合并成单一的 Schnorr 聚合签名，由合约在链上验证。SSP 的 smart contracts 已于 2025 年由 Halborn 审计。完整设计是 SSP 账户抽象架构的主题。
换句话说，上文描述的那种抽象能力——一个强制执行自身多签规则的账户——正是 SSP 在 Ethereum、Polygon、Base 以及其他受支持的 EVM 链上转化成的一款可用钱包。
本系列的其余部分
本篇搭好了问题与核心理念。本系列从这里继续展开：
- 从第一性原理理解账户抽象 — 本文：为什么 EOA 是受限的，以及账户抽象意味着什么。
- EOA 与 smart account：真正重要的区别 — 对两种账户模型的直接比较。
- SSP 账户抽象架构 — SSP 如何把 ERC-4337 接入一个 2-of-2 钱包。
- Gas 代付与 paymasters 详解 — paymasters 如何把"谁付费"与"谁发送"解耦。
- 非 Ethereum 链上的账户抽象 — 同一个理念如何越过 Ethereum 传播开来。
如果你想单独了解这个标准，就先从 ERC-4337 讲解开始，然后再回到这里看全局。从此之后，账户不再是一种约束，而开始成为你可以围绕其编程的东西。
