EOA 与 smart account：真正重要的区别
如果你使用过加密钱包，就使用过账户。但 Ethereum 上的账户并非都一样。账户有两种根本不同的类型，而这种差异几乎决定了你钱包的所有行为：你如何签名、谁可以授权一笔付款、你如何恢复访问权限、谁支付手续费，以及用哪种代币支付。
本文将逐一介绍这两种账户类型——外部拥有账户（EOA）和 smart account——并按照自托管用户日常真正能感受到的几个维度对它们进行比较。这是我们 account abstraction 系列的第二篇文章；如果你还没有读过 从第一性原理理解 account abstraction，那是一个不错的起点。这里我们专门聚焦于 EOA 与 smart account 之间的区别。
什么是 EOA？
外部拥有账户是 Ethereum 最初的账户。它由恰好一对 secp256k1 密钥定义：一个私钥，以及由它派生出的公钥。你看到的地址——那个 0x... 字符串——就是由该公钥派生而来。谁持有私钥，谁就控制该账户，就这么简单。
那一把密钥完成所有工作。它用一个 ECDSA 签名为每一笔交易签名。账户上没有附加任何代码，没有规则，也没有条件。当一笔交易到达时，网络唯一的问题是：「这个签名对这个地址是否有效？」如果有效，交易就执行。
你接触过的大多数浏览器扩展钱包——MetaMask 风格的单密钥模型——创建的都是 EOA。一条助记词派生出密钥，密钥控制账户，而保护那条助记词就是全部的安全模型。它简单、易懂，并且已经运行了十年。它也很僵化：一把密钥、一个签名者、一种签名方案，一旦那把密钥泄露，账户就没了。
什么是 smart account？
smart account 是一个合约账户：它的行为由部署的代码定义，而不是由单一密钥定义。账户不再判断「这一个 ECDSA 签名是否有效」，而是运行自己的验证逻辑来决定是否接受某项操作。这套逻辑是可编程的。
因为规则存在于代码中，smart account 可以要求两个签名而不是一个，可以接受 ECDSA 以外的签名方案，可以强制执行支出限额，或者定义一条恢复路径——只要它的合约这样规定即可。Safe 风格的智能合约钱包就是这种模型的著名例子。在 Ethereum 和其他 EVM 链上，让这些账户在不改变协议的情况下表现得像一等账户的标准是 ERC-4337。
控制权：一把密钥与自定义规则
这是最主要的区别。EOA 在协议中固化了恰好一条规则：来自一把密钥的一个有效 ECDSA 签名授权一切。没有办法添加第二个必需的批准者，也没有办法规定「超过此阈值的金额需要额外确认」。密钥就是账户。
smart account 自己做决定。它可以要求多签法定人数、限制某些操作，或叠加会话密钥。SSP 利用这一点来实现 2-of-2 multisig：一把密钥保存在 SSP Wallet 浏览器扩展中，第二把保存在 SSP Key 移动应用中，账户的验证逻辑要求两者都批准之后才接受任何交易。仅有一个被泄露的浏览器扩展无法转移资金，因为合约根本不会接受单密钥授权。
恢复：当密钥丢失时会发生什么
对于 EOA，密钥就是账户。丢失助记词，账户就无法恢复；助记词泄露，攻击者就拥有完全控制权。没有内置的补救措施，因为没有可以诉诸的逻辑——只有那一把密钥才重要。
smart account 可以把恢复作为其规则的一部分来定义。因为验证是可编程的，合约可以指定替代的授权路径、指定的恢复方，或带时间延迟的密钥轮换。SSP 的具体模型是 2-of-2：失去对任一设备的访问权限都不会把你的资金交给攻击者，因为两个签名始终都是必需的。其实际效果是：没有任何单一设备会成为单点故障。
谁支付 gas，以及用哪种代币
EOA 为自己的交易付费，并且用链的原生币支付。要在 Ethereum 上转移一个 ERC-20 代币，EOA 仍然需要 ETH 来支付 gas。如果你的账户持有代币却没有 ETH，你就被卡住了——这是新手常见且令人沮丧的经历。
smart account 可以打破这种关联。在 ERC-4337 之下，一个名为 paymaster 的组件可以为某项操作赞助 gas，或接受用原生币以外的代币付款。手续费可以由第三方承担，也可以用你正在转移的同一种代币支付。我们在 gas 赞助与 paymaster 详解 中对此有详细介绍；这里的要点是「谁付费，以及用什么付费」不再是固定的。
批量执行多个操作
对于 EOA，每一笔交易都是一个单独的、逐一签名的操作。经典的 ERC-20 模式——先授权某个合约花费你的代币，再调用该合约——是两笔交易、两个签名、两次 gas 支付，依次进行。
smart account 可以把多个操作打包进单个操作中，要么完全成功，要么完全回滚。授权并兑换变成了单一步骤。这部分是为了便利，部分是为了安全：不存在那种你已经授予了授权但后续操作却从未发生的半完成状态。
签名方案
EOA 只验证一件事：基于 secp256k1 的 ECDSA 签名。这是协议为外部拥有账户检查的唯一方案，且无法更改。
smart account 验证其代码被编写来验证的任何东西。它可以检查多个签名、特殊曲线，或聚合签名。SSP 的 EVM 账户验证一个 Schnorr 聚合签名：来自浏览器扩展和移动应用的两个部分签名——以 MuSig2 风格、基于 secp256k1——合并成一个由合约验证的单一 on-chain 签名。链上看到的是一个签名；其背后的安全模型却是两个独立的批准者。这是 EOA 在结构上无法做到的。
部署与地址
EOA 在密钥存在的那一刻就存在了。离线生成一对密钥，对应的地址就已经有效；它不花费任何成本，也不触及任何合约。账户就是单纯地存在。
smart account 是一个合约，因此在它能够承载由代码定义的行为之前，必须先在链上部署。在实践中，ERC-4337 钱包使用一个确定性的反事实地址：该地址根据账户的参数预先计算出来，因此它可以在合约真正部署之前就接收资金，而部署在首次使用时发生。你可以分享你的地址并在任何部署交易落地之前就收到付款。
成本：诚实的权衡
可编程性并非免费。因为 smart account 在合约中运行验证逻辑，它的操作所花费的 gas 比普通 EOA 转账要多一些，而后者已是 Ethereum 交易中最便宜的那一类。首次部署账户也有一次性成本。
对大多数自托管用户来说，为换取双密钥安全性、恢复选项、批量执行和灵活的 gas，这是一个合理的代价。但这是一个真实的差异，值得清楚地点明，而不是含糊带过。
SSP 使用什么，以及每种模型何时合适
直接说：SSP 通过 ERC-4337 使用一个 smart account 来实现它的 2-of-2 multisig，覆盖 EVM 链——Ethereum、Polygon、Base、BNB Smart Chain 和 Avalanche。该合约要求一个由你的两台设备共同构建的 Schnorr 聚合签名，并且 SSP 的 EVM 实现已于 2025 年由 Halborn 审计。要了解这些组件如何协同工作，请阅读 SSP account abstraction 架构，而关于链的具体细节请参阅 SSP 中的 Ethereum。
那么每种模型何时合适？EOA 是可能最简单的账户：最便宜的 gas、即时存在、无需部署。对于以简单为优先的单用户、单密钥设置，它完全够用。当你想要单一密钥无法给予你的特性时，smart account 就有意义了——多个必需的批准者、恢复逻辑、批量执行、被赞助的或以代币计价的 gas。其代价是略高的 gas 以及部署这一概念。
对于一个其全部前提就是「任何单一密钥都不应成为单点故障」的自托管钱包来说，smart account 是自然的选择。这正是 SSP 构建于其上的原因。要更深入地了解 Ethereum 账户模型本身，Ethereum 账户文档 是权威参考，而 ERC-4337 规范 则是让 smart account 在今天切实可用的标准。
