在探索的过程中，Ethereum 提出了 ERC-4337、EIP-3074 和 EIP-7702 等账户抽象解决方案。而其他公链比如 Solana 则存在 Program Derived Addresses (PDA) 这种类似账户抽象的方案，Cosmos 也有 x/authz 这类相似设计。

撰文：Zeqing Guo、Jinming Neo

为什么要有账户抽象？

当前区块链领域还有很多没被解决的问题，其中区块链的使用难度，也就是与链交互的用户体验（UX）一定是被公众诟病最多的一个领域。比如说，很多人认为使用密钥比使用邮箱管理账户要复杂；密钥管理难度高不安全感强；每次转账（例如转 USDC）需要消耗 native token（例如 Ether 和 Sol）违反直觉。在这个背景下，越来越多的人把目光投向了账户抽象领域，以此改善链上交互的用户体验，让区块链更容易被大范围采用（mass adoption）。

在探索的过程中，Ethereum 提出了 ERC-4337、EIP-3074 和 EIP-7702 等账户抽象解决方案。而其他公链比如 Solana 则存在 Program Derived Addresses (PDA) 这种类似账户抽象的方案，Cosmos 也有 x/authz 这类相似设计。本文我们将介绍和对比上述几种方案，梳理不同方案设计的精妙之处，并展示不同方案的取舍考量。

背景

EOA 账户与合约账户

EOA 账户（Externally Owned Account）和合约账户是定义在以太坊白皮书中的两种账户类型。EOA 账户由私钥控制，用户可以通过私钥签名各类交易以控制账户内的资产。合约账户由账户本身的代码控制，其他账户可以通过调用合约账户的代码来让合约账户执行特定逻辑。

账户抽象

账户抽象的概念最早可以追溯到 2016 年（https://github.com/ethereum/EIPs/issues/86 ），其意义是在目前以太坊两种账户类型——EOA 账户、合约账户——之上抽象出一种统一的账户类型，也就是账户抽象。这将改善以太坊用户的交互体验：

1. 允许用户使用多种签名，比如 Schnorr, BLS, post-quantum 签名等；
2. 允许用户使用 ERC20 代币或者自定义付费逻辑支付 gas fee；
3. 允许用户使用邮箱、社交等方法找回账户；
4. 允许用户采用细粒度权限管理自己账户的资金，比如设置每天提现上限；
5. 允许一次原子交易中执行多笔链上操作，比如用户一次签名就可以完成 DEX 交易中的 approve 和 swap 两个操作。

以太坊路线图

以太坊路线图（https://ethereum.org/en/roadmap/）是以太坊未来的升级路线，目前以太坊社区的大多数研究都是围绕着以太坊路线图展开。账户抽象是其中的重要组成部分：

来源: https://x.com/VitalikButerin/status/1741190491578810445

以太坊社区希望从接下来会介绍的 ERC-4337 出发，转换 EOA 账户为账户抽象，并且实现协议内的账户抽象方案（例如接下来会介绍的 EIP-3074 和 EIP-7702）最后达到 Endgame account abstraction。Endgame account abstraction 除了对用户交互体验有重要意义外，同时也对以太坊的抗量子计算至关重要，因为目前的 EOA 账户使用的 ECDSA 算法在量子计算时代是不安全的，可以通过 EOA 转换为账户抽象的方法，让以太坊账户支持 post-quantum 签名。

EIP-3074 与 ERC-4337

要理解账户抽象，首先让我们来了解一下以太坊目前最主流的 EOA 账户的工作流程，下图是链上最常见的代币买卖流程：

用户在买卖时需要发出两笔交易：先授权 Uniswap 划转自己的 USDC，再向 Uniswap 发送交易请求，Uniswap 划转用户账户的 USDC，并按照当前价格发送对应数量的 ETH 给用户。ERC-4337 简化了上述步骤：

从上图可见，用户需要做两次签名，授权 bundler 操作用户在链上托管在 4337 account（并非用户的 EOA account ）里的资产。Bundler 获得授权后将授权内容合并为一个交易发出。同时，如果用户没有以太坊代币当 gas fee 时，也可以引入 paymaster 的角色，让 paymaster 支付 gas fee 并获得用户等价值的 ERC20 代币。

EIP-3074 和 ERC-4337 有一些相似，但是 EIP-3074 的实现方法更加底层：

在 ERC-4337 中，我们通过签名授权 bundler 处理我们的链上智能合约钱包中的资产。在 EIP-3074 中则是通过签名授权 bundler 直接处理我们 EOA 钱包中的资产。为了做到这件事，以太坊社区需要在以太坊协议中加入两个新的操作码（op code）：AUTH 和 AUTHCALL。AUTH 用来验证 bundler 处理用户 EOA 账户资产的行为是否得到授权，AUTHCALL 用来「骗过」用户交互的智能合约（在我们的例子中是 USDC 和 Uniswap），让智能合约以为是用户的 EOA 账户发出的请求。这样做的好处是 Uniswap 和 USDC 的维护者不需要升级已经部署的智能合约，同时 EOA 账户又能享受到账户抽象的功能。

EIP-3074 与 ERC-4337 的比较

在以太坊社区，EIP 一般指需要以太坊升级才能支持的协议，ERC 则是不需要以太坊升级也能支持的协议。所以从两个账户抽象方案的命名可以看出，ERC-4337 更容易被实现，因为它不需要硬分叉就可以实现。这也是 ERC-4337 已经上线，并且在 polygon 和 base 上被越来越多使用，但是 EIP-3074 刚被 183 次 Ethereum All Core Developers Execution Call(ACDE) 接受的一个原因。

来源: https://dune.com/niftytable/account-abstraction

除此之外，ERC-4337 需要用户将当前账户迁移至新的合约账户，并且需要 DApp 支持 EIP-1271 才能使用 ERC-4337。 EIP-3074 则不需要这些额外支持。这是导致 ERC-4337 采用率不高的一大原因。同时 ERC-4337 在不引入中间 multi call 合约的情况下，无法支持一次签名授权多次链上操作，但是 EIP-3074 可以，这也造成了 ERC-4337 的局限性。

不过 EIP-3074 也有自己的问题，最主要的就是操作码 AUTH 权限太高，实施不当，可能让攻击者完全控制用户的 EOA 账户。毕竟只要黑客骗取了您的 AUTH 签名，就可以处置您 EOA 钱包内的资产。考虑到目前钓鱼攻击猖獗，而且大多是骗取用户的签名，当 EIP-3074 实施，这会变成一个比较严重的问题。对此，EIP-3074 的作者 lightclient 提出过缓解的办法，通过钱包层面拦截恶意签名，具体可参考：https://x.com/lightclients/status/1778823652584120497。ERC-4337 则不会有这个问题，虽然黑客也可以骗取用户签名恶意的 UserOp，但是一个 UserOp 一般很难得到用户账户内所有资产的处置权限。在撰写本文时，ACDE 开发者们同意从 Pectra Devent 0 中移除 EIP-3704，并在下一个 Pectra Devnet 1 中包含 EIP-7702。

EIP-7702 又改进了什么？

EIP-7702 试图融合 EIP-3074 和 ERC-4337 两边的成果，形成一条中间路线。用户将签名好的操作发给 bundler，bundler 上链交易时用户的 EOA 账户会临时变成智能合约账户（比如 4337 账户）。接下来和 EIP-3074 中的 AUTH 过程一样，该智能合约账户会将用户授权 bundler 的操作标记为合法。之后如同 AUTHCALL，执行用户授权的操作。执行完交易后，用户账户回滚会普通的 EOA 账户。

该方案的好处如下：

1. 继承了 EIP-3074 的所有优点：不需要用户从 EOA 账户切换至新地址的智能合约账户；能够在一次原子交易中执行多个操作；
2. 可以复用 ERC-4337 的智能合约账户代码以及基础设施；
3. 可以合并 ERC-4337 为代表的智能合约账户抽象和以 EIP-3074 为代表的 EOA 账户抽象方案，防止以太坊分裂出两套不同的账户抽象系统，为以太坊路线图中的 Endgame Abstraction Account 铺路；
4. 不会在以太坊的 EVM 里增加 AUTH 和 AUTHCALL 两个 op code，考虑到以太坊路线图，未来 EOA 账户会被转换为账户抽象，届时这两个 op code 会变得多余。

除此之外，EIP-7702 继承了来自 EIP-3074 的所有安全风险。

目前 EIP-7702 已经被 ACDE 放入了 2025 年的 Pectra 升级之中。如果实施将会极大改变以太坊生态，并且为当前 ERC-4337 版本账户抽象的基础设施带来增量。

Solana 的程序派生地址

在 Solana 上的账户抽象

Solana 的账户抽象类似以太坊 ERC-4337，是由原始账户（类似 EOA 账户）派生出的账户（类似 4337 合约账户）。在了解 Solana 账户抽象前，我们有必要了解 Solana 使用的账户模型。

广义上说，账户可以分为可执行账户和不可执行账户两类。进一步来说，在 Solana 上有三种类型的账户：本地程序账户（Native Program）、程序账户（Program Account）和数据账户（Data Account）。

本地程序是验证器实现的一部分，为 Solana 网络提供核心功能，如创建新的数据账户和自定义程序。程序账户是包含可执行代码的自定义程序。数据账户可以存储数据，并根据其所有者程序账户的定义管理程序状态。

这种账户模型本地支持程序账户创建和管理特定账户，为开发人员提供了定义自定义规则和逻辑以管理它们的能力。借助这种账户模型，程序派生地址（PDA），一种数据账户类型，将 Solana 上的账户抽象能力扩展到从增强用户安全性（通过多签钱包和两步验证等方式）到启用社交恢复机制等多个方面。

程序派生地址（PDA）

为了了解背景，所有账户都位于 Ed25519 曲线上，并具有公私钥对。PDA 位于 Ed25519 曲线之外，是一个确定性派生的 32 字节字符串，看起来像一个公钥，并且没有相应的私钥。PDA 允许开发人员创建自定义规则和交易签名机制，使得 PDA 的程序账户所有者能够代表 PDA 自主进行交易，也得到 Solana 网络的支持。

PDA 和账户抽象

既然我们了解了 PDA 是如何派生的，您可能会想知道这些概念如何与账户抽象联系起来。账户抽象通过名为跨程序调用（CPI）的函数在底层实现。CPI 是一种使一个程序能够调用另一个程序的指令的函数，允许 Solana 程序的可组合性。当一个程序通过 invoke_signed 发起 CPI 时，程序能够代表其程序 ID 派生的 PDA 进行签名。

来源: Solana

为了验证涉及 PDA 的交易的合法性，Solana 运行时会在内部使用签名者种子和调用程序的程序 ID 调用 create_program_address。如果找到有效的 PDA，该地址将被添加为有效签名者。运行时还会使用授予调用程序的权限来确定可以扩展到被调用程序的权限。

当前 Squads 正在基于 PDA 开发 Solana 上的账户抽象方案，不过目前 Squads 提供的产品更加类似于 Gnosis Safe 的智能合约账户方案，还没有完善其账户抽象的功能。

PDA 的好处

1. 自动化智能合约执行：PDA 允许更复杂的智能合约设计，通过跨程序调用可以自主地代表用户执行多个操作。
2. 增强用户体验：用户不需要管理多个交易或接触技术复杂性。
3. 增强的安全性和灵活性：没有私钥，这可以减少密钥泄露的风险。PDA 可以用于多签名钱包或适应其他灵活的治理模型，从而减少单点风险，对于管理大量共享资源的组织特别有用。

程序派生地址的限制

1. 尽管 PDA 在为账户抽象能力奠定基础方面具有优势，但与密钥对账户相比，其实现起来可能更为复杂。
2. 和 ERC-4337 一样，它需要用户进行账户迁移，这可能会抑制 Solana 账户抽象的使用率。

Cosmos 上的账户抽象 (Authz & Fee Grant)

Cosmos 上的 x/authz

随着账户抽象越来越受到开发者的关注，Cosmos SDK 核心组建推出了 authz 模块，以允许一个账户通过使用授权许可来代表另一个账户执行某些操作，这种设计思路比较类似与 EIP-3074 和 EIP-7702。

Authz 提供了更全面的授权类型，开启了抽象各种复杂性的可能性，这些复杂性以前导致了次优的用户体验。

通过 authz，可以给予三种类型的授权：

• 通用授权（GenericAuthorization）。这种授权许可给予受让人无限制的权限，以代表授予人执行消息。
• 发送授权（SendAuthorization）。这种授权旨在给予受让人访问授予人账户某一资产的最大数量。
• 质押授权（StakeAuthorization）。这种授权允许受让人代表授予人管理质押操作，如委托、撤销委托或重新委托。

一个授权包括授予人的地址字节、受让人的地址字节和授权类型。还可以定义时间段以限制在特定时间段内的权限。在每个区块结束时，网络将移除过期的授权。

理解操作框架

Authz 可用于授予各种操作的授权，但为了简单起见，我们将看一下 authz 如何工作以启用通用投票交易。

1. 在执行任何授权之前，需要实现授权接口。在此阶段，还将定义消息类型，本例中为 MsgVote。在这里，我们看到 Alice 授予了对治理投票行动的授权。
2. Bob 生成未签名的投票交易。
3. Bob 生成由 Alice 签署并执行的投票交易。如果授权已过期，交易将完成并且授权将被移除。

Authz 带来的好处是什么？

• 操作安全性：验证人和其他用户可以授予单独的账户权限，以投票支持治理提案或执行特定操作，增强账户安全性并减轻安全负担。
• 简化操作：可以进行交易而无需访问验证人密钥，多重签名钱包交易也可以使用单个交易来向受让人账户授予 authz 以简化操作。
• 不需要迁移账户：和 EIP-3074、EIP-7702 类似，用户可以在现有账户上使用 authz，不需要把资产迁移到新账户。
• DAO 的操作效率和灵活性：可以为特定操作向个体 DAO 成员授予执行权限的子集。
• 质押奖励复利：authz 促进了对 restaing 和类似服务的使用，以实现质押奖励的自动复利。

Authz 的限制和风险：

• 注意通过 authz 授权的交易类型。恶意的 MsgGrant 可以执行各种类型的授权，可能对用户造成损害。
• 通用授权：给予他人受让人账户的无限授权，如果黑客利用钓鱼攻击骗取受让人签名，会导致受让人账户资产被盗。有些钱包在签署 authz 交易时可能不会提供警告。
• 发送授权：允许受让人发送授予人未指定的最大数量的代币。重要的是要验证 AllowList，该列表指定了受让人可以将代币发送到的具体地址。

Fee grant 模块

另一个让用户体验受挫的障碍是区块链用户需要持有各种本地代币才能与这些不同的生态系统互动。这对那些首次接触 Cosmos 生态系统中众多链条的非加密本地用户来说，整体用户体验受到了影响。然而，通过 fee grant 模块的整合可以改善用户体验。类似于在以太坊上实现账户抽象的 paymaster 合约，Cosmos 上的 fee grant 模块允许授予者向受益者授予交易手续费额度，支付部分或全部交易费用。资金仍然由授予者控制，并且可以随时撤销授予的额度。

Fee grant 类型

手续费津贴可以分为两种类型：基本津贴（BasicAllowance）和定期津贴（PeriodicAllowance)。

基本津贴允许受让人使用授予人账户中的费用，直到达到消费限额或到期时间。然后，该授权将从状态中终止。需要注意的是，基本津贴实施的是一次性费用授权。如果消费限额和时间为空，则费用津贴没有到期和消费上限。

定期津贴使费用授权在每个指定的时间段后定期更新。period_spend_limit 指定了该期间内可以花费的最大金额。period_reset 跟踪下一个期间应该何时开始，period_can_spend 跟踪新期间开始前剩余的可花费金额。

理解操作框架

使用 AllowedMsgAllowance 可以为指定的消息类型创建津贴。津贴可以是基本津贴（BasicAllowance）或定期津贴（PeriodicAllowance）。如果设置了到期时间，FeeAllowance 将在状态中排队，并在授权后附加到期前缀，Endblocker 会检查 FeeAllowanceQueue 状态中是否有到期的授权，如果发现则将其剔除。除了 MsgGrantAllowance 之外，费用额度也可以通过 MsgRevokeAllowance 撤销。

总体而言，authz 和 Fee Grant 模块解锁了创新和多样的用例，最终在 Cosmos 生态系统中打造了更好的用户体验。

对比与总结

账户抽象

截至 2024 年 5 月 27 日，数据估计。

随着现货比特币 ETF 和以太坊 ETF 的批准，机构和零售投资者的需求大幅增加，预示着将迎来一波寻求行业曝光的新用户。随着协议和 DApp 寻求创造无缝体验来扩大其社区，账户抽象将成为今年重要的叙事。

参考资料

Solana

An Introduction to Account Abstraction - Squads Blog

Program Derived Address (PDA) | Solana

Exploring Account Abstraction Use Cases - Squads Blog

https://solanacookbook.com/core-concepts/pdas.html#facts

https://solana.wiki/zh-cn/docs/ethereum-comparison/

https://www.brianfriel.xyz/understanding-program-derived-addresses/

https://twitter.com/pencilflip/status/1451949964091924483

https://www.alchemy.com/overviews/cross-program-invocation

https://www.quicknode.com/guides/solana-development/anchor/how-to-use-program-derived-addresses

What is a PDA on Solana? [Solana Tutorial] - Mar 15th '22

Solana Tutorial: Creating PDA's with Anchor 

https://www.youtube.com/watch?v=ZwFNPvqUcl

https://www.alchemy.com/overviews/program-derived-address

Cosmos

Account abstraction for Cosmos - demo #2 - authz grant

Account abstraction | Secret Network

Authz Overview | Cosmos SDK 

AuthZ Delegated Multi-sig - MilkyWay Zone

GitHub - larry0x/abstract-account: An account abstraction solution for CosmWasm-enabled chains 

https://www.dydx.foundation/blog/dydx-chain-4-0-software-upgrade

https://dydx.forum/t/info-authz-module-its-wonders-and-risks/2348

https://forum.cosmos.network/t/voting-period-signaling-proposal-add-the-fee-abstraction-module-to-the-cosmos-hub/11127

https://docs.cosmos.network/main/build/modules/feegrant#abstract

Ethereum

https://eips.ethereum.org/EIPS/eip-3074

https://eips.ethereum.org/EIPS/eip-7702 

https://www.erc4337.io/docs/understanding-ERC-4337/architecture 

https://x.com/lightclients/status/1778823652584120497

https://github.com/ethereum/EIPs/issues/86

https://x.com/VitalikButerin/status/1741190491578810445

https://medium.com/taipei-ethereum-meetup/eip3074-%E7%B0%A1%E4%BB%8B-2a880b918234