账户抽象：提升区块链交互体验的关键

作者: Zeqing Guo, Jinming Neo

我们为什么需要账户抽象？

当前区块链领域仍然存在许多尚未解决的问题。其中，区块链使用的困难，即与链交互的用户体验（UX），必定是公众最为批评的领域。

例如，许多人认为使用密钥管理账户比使用电子邮件更复杂；密钥管理困难且不安全；每次转账（例如 USDC）都需要消耗原生代币（例如以太坊和 Sol），这与直觉相悖。

在这种背景下，越来越多的人将目光转向账户抽象的领域，以改善链上交互的用户体验，并促进大众采用。

在探索过程中，以太坊提出了如 ERC-4337、EIP-3074 和 EIP-7702 等账户抽象解决方案。其他 L1，如 Solana，具有允许协议级账户抽象的特性，如程序衍生地址（Program Derived Addresses, PDA），而 Cosmos 也有类似的设计，如 x/authz 和费用抽象模块。在本文中，我们将介绍并比较上述解决方案，理清不同解决方案设计的微妙之处，并展示不同解决方案的权衡和考虑。

背景

EOA 与合约账户

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

账户抽象

账户抽象的概念可以追溯到2016年（https://github.com/ethereum/EIPs/issues/86）。账户抽象基于以太坊中现有的两种账户类型——EOA 和合约账户，改进以太坊用户的交互体验，具体方式如下：

1. 允许用户使用多种签名，例如 Schnorr、BLS、后量子签名等；
2. 允许用户使用 ERC20 代币或自定义支付逻辑支付 gas 费用；
3. 允许用户通过电子邮件、社交媒体等方式找回其账户；
4. 允许用户对账户中的资金进行精细化权限管理，例如设置每日提款限额；
5. 允许在一次原子交易中执行多项链上操作。例如，用户可以在一次 DEX 交易中同时完成批准和交换操作。

以太坊路线图

以太坊路线图（https://ethereum.org/en/roadmap/）突出了以太坊未来的升级路线。目前，以太坊社区的大部分研究都围绕着以太坊路线图展开。账户抽象是其中不可或缺的一部分：

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

以太坊社区希望在 ERC-4337 的基础上，通过 EIP-3074 或 EIP-7702 等提案实现协议内部的账户抽象解决方案，并最终达到最终游戏（Endgame）账户抽象。

除了改善用户体验外，最终游戏账户抽象对以太坊的抗量子计算能力也至关重要，因为当前 EOA 账户使用的 ECDSA 算法在量子计算时代是安全的。采用账户抽象支持后量子签名，以保护用户账户免受不断演变的量子计算威胁。

EIP-3074 与 ERC-4337

要理解账户抽象账户，我们需要理解 EOA 的工作原理。下面的图片是链上最常见的代币购买和出售过程：

一般来说，用户在购买和出售时需要发出两笔交易：首先授权 Uniswap 转移他们的 USDC 进行交换，然后再发送另一笔交易请求，要求 Uniswap 执行该操作。Uniswap 转移用户账户的 USDC，并根据当前价格向用户发送相应数量的 ETH。

ERC-4337 将以上两笔交易合并为一笔：

从上图可以看出，用户需要签署两次，以授权捆绑者（bundler）在 4337 账户中操作用户的资产，这与用户的 EOA 账户有所不同。在捆绑者获得授权后，它将授权内容合并成一个捆束（bundle），并发出以完成交易。同时，如果用户没有以太坊用于支付 gas 费用，可以引入支付者（paymaster）的角色，允许支付者支付 gas 费用并从用户那里获得等值的 ERC20 代币。

EIP-3074 和 ERC-4337 有一些相似之处，但 EIP-3074 的实现方式在以太坊协议中：

在 ERC-4337 中，我们通过签名授权捆绑者处理我们链上的智能合约钱包中的资产。在 EIP-3074 中，捆绑者被授权直接处理我们 EOA 钱包中的资产。同样，为了实现这一点，以太坊社区需要向以太坊协议添加两条新操作码：AUTH 和 AUTHCALL。

AUTH 用于验证捆绑者处理用户 EOA 账户资产的行为是否被授权，而 AUTHCALL 用于“愚弄”用户交互的智能合约（在我们的例子中是 USDC 和 Uniswap），使得智能合约认为交易是由用户的 EOA 账户发起的。这样做的好处在于，Uniswap 和 USDC 的维护者不需要升级已部署的智能合约，同时 EOA 账户可以享受账户抽象的功能。

EIP-3074 与 ERC-4337 比较

在以太坊社区中，EIP 通常指需要支持以太坊升级的提案，而 ERC 指可以在不进行以太坊升级的情况下获得支持的规范。

因此，从这两个账户抽象方案的命名可以看出，ERC-4337 比 EIP-3074 更容易实施，因为 ERC-4337 不需要进行以太坊网络的硬分叉。这也是 ERC-4337 已经上线并在 polygon 和 base 上越来越多地使用的原因之一，而 EIP-3074 刚刚被第 183 次以太坊全核心开发者执行电话会议（ACDE）接受。

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

此外，ERC-4337 要求用户将当前账户迁移到新的合约账户，并且需要 DApp 支持 EIP-1271 才能正常运行。EIP-3074 则不需要这些额外的支持。这是 ERC-4337 采用率低的主要原因。同时，ERC-4337 不能支持单个签名授权多个链上操作，而不引入中间的多调用合约（multi-call contract），但 EIP-3074 可以，这也导致了 ERC-4337 的局限性。

然而，EIP-3074 也有自身的问题。最重要的一点是，操作码 AUTH 的权限过高，可能允许攻击者完全控制用户的 EOA 账户。毕竟，只要黑客欺骗你签名 AUTH，他就可以处置你 EO 账户中的资产。考虑到目前网络钓鱼攻击猖獗，而且大多数都是欺骗用户签署，一旦实施 EIP-3074，这将成为一个更严重的问题。

在这方面，EIP-3074 的作者之一 lightclient 提出了缓解方法，通过钱包层拦截恶意签名。详情请参见：https://x.com/lightclients/status/1778823652584120497。尽管 ERC-4337 没有这一问题，黑客仍然可以欺骗用户签署恶意的 UserOps。这是因为 UserOp 获得对用户账户中所有资产的处理权限的可能性较小。到本文撰写时，ACDE 中的开发者已经同意将 EIP-3704 从 Pectra Devnet 0 中删除，并在下一个 Pectra Devnet 1 中加入 EIP-7702。

EIP-7702 有什么变化？

EIP-7702 试图整合 EIP-3074 和 ERC-4337 的优势，以形成中间路径。用户将签名操作发送给捆绑者。在捆绑者将交易发送到链上时，用户的 EOA 账户将暂时变为类似 4337 账户的智能合约账户。接下来，类似于 EIP-3074 中 AUTH 的进展，智能合约账户将验证用户授权的捆绑者操作。然后，就像 AUTHCALL 一样，执行用户授权的操作。在执行交易后，用户账户将恢复为普通 EOA 账户。

EIP-7702 的好处如下：

1. 继承了 EIP-3074 的所有优势：不需要用户从 EOA 账户切换到具有新地址的智能合约账户；可以在一次原子交易中执行多个操作；
2. 可以重用 ERC-4337 的智能合约账户代码和基础设施；
3. 代表 ERC-4337 的智能合约账户抽象和代表 EIP-3074 的 EOA 账户抽象解决方案可以合并，防止以太坊分裂为两个不同的账户抽象系统，并为以太坊路线图中的最终游戏抽象账户铺平道路；
4. 不会向以太坊的 EVM 添加两个操作码 AUTH 和 AUTHCALL：考虑到以太坊路线图，EOA 账户将在未来转换为账户抽象，而这两个操作码将变得冗余。

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

社区决定在 2025 年的下一个 Pectra 升级中包含 EIP-7702。如果实施，将大大改变以太坊生态系统，并为当前 ERC-4337 版账户抽象基础设施带来增量改进。

Solana 的程序衍生地址

Solana 上的账户抽象

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

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

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

这种账户模型本质上使程序账户能够创建和管理特定账户，为开发者提供定义自定义规则和逻辑的能力。通过这种账户模型启用的程序衍生地址（PDA），是一种数据账户，扩展了 Solana 上账户抽象能力的可能性，从通过多签钱包和双因素身份验证增强用户安全，到启用社交恢复机制等。

程序衍生地址

在此背景下，所有账户都位于 Ed25519 曲线上，并具有公私钥对。PDA 位于 Ed25519 曲线之外，是一个确定性派生的 32 字节字符串，形状类似公钥，但没有对应的私钥。PDA 允许开发者创建自定义规则和交易签名机制，使 PDA 的程序账户拥有者能够自主地代表 PDA 执行交易，完全被 Solana 网络识别和支持。

PDA 与账户抽象

现在既然我们了解了 PDA 是如何派生的，你可能想知道这些概念如何与账户抽象相关联。账户抽象在后台通过一个称为跨程序调用 （Cross Program Invocation, CPI）的函数进行。

CPI 是一种使程序能够调用另一个程序指令的函数，允许 Solana 程序的组合。当程序通过 invoke_signed 发起 CPI 时，程序能够代表派生的 PDA 签名。

来源: Solana

为了验证涉及 PDA 交易的合法性，Solana 运行时会内部调用 create_program_address，使用 signers_seeds 和调用程序的 program_id。如果发现有效的 PDA，运行时将把 PDA 与调用程序关联，并将该程序识别为授权的签名者。

目前，Squads 正在开发一个基于 PDA 的 Solana 上账户抽象解决方案。然而，Squads 提供的产品目前更类似于 Gnosis Safe 的智能合约账户解决方案，尚未完全开发账户抽象功能。

PDA 的好处

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

PDA 的局限性

1. 尽管 PDA 为账户抽象能力奠定基础，但相较传统密钥对账户，其实现可能更加复杂。
2. 和 ERC-4337 一样，它要求用户将账户迁移到新账户，这可能抑制 Solana 账户抽象的采用率。

Cosmos 上的账户抽象（Authz 和费用补助）

Cosmos x/authz

随着账户抽象逐渐占据开发者的思维空间，authz 作为 Cosmos SDK 的核心部分推出，允许一个账户代表另一个账户执行某些操作，使用的授权管理类似于 EIP-3074 和 EIP-7702。

Authz 提供了几种预定义的授权类型，代表受赠人执行某些操作，如质押，从而提高用户体验。

使用 authz，可以授予 3 种类型的 授权：

1. GenericAuthorization（通用授权）。 此授权授予受赠人无限制的权限，以代表赠予人执行消息。
2. SendAuthorization（发送授权）。 此授权类似于 ERC20 中的批准，旨在给予受赠人的支出限额，该限额定义了可以代表赠予人支出的最大金额。
3. StakeAuthorization（质押授权）。 此授权允许受赠人代表赠予人管理质押操作，如委托、解除委托或重新委托。

授权包括 赠予人地址的字节、受赠人地址的字节和授权类型。也可以定义时间段以限制权限在特定时间内保持有效。每个区块结束时，网络将通过一种称为修剪的过程删除过期的授权。

理解操作框架

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

1. 在执行任何授权之前，实现授权接口。在这个阶段，消息类型也将被定义，在本例中将是 MsgVote。这里，我们看到来自 Alice 的授权，用于治理投票行为。
2. Bob 生成一笔未签名的投票交易。
3. Bob 生成一笔已签名并执行的投票交易。交易完成后，授权将在过期时被移除。

authz 带来了哪些好处？

1. 操作安全：验证者和其他用户可以授予单独账户的权限，以在治理提案上投票或执行某些操作，提高账户安全性并降低安全负担。
2. 操作精简：交易可以在不需要访问验证者密钥的情况下执行，而多签钱包交易也可以通过单个交易流线化，以授权用户账户。
3. 无需迁移：类似于 EIP-3074 和 EIP-7702，授权操作发生在用户的原始账户中。用户无需将资产从原始账户转移到新账户，即可启用账户抽象。
4. DAO 操作效率和灵活性：可以给个别 DAO 成员赋予特定行动的执行权。
5. 质押奖励复合：Authz 促进再质押和等同服务的使用，实现质押奖励的自动复合。

Authz 的局限性和风险：

请注意你通过 Authz 授予的授权类型。恶意的 授权 可能执行各种类型的授权，这对用户可能是有害的。

1. GenericAuthorization：赋予表现 无限制权限 代表赠予人执行所提供的消息。除非完全意识到你在签署的内容，切忌签署此类授权类型。一些钱包可能在签署 Authz 交易时没有提供警告。
2. SendAuthorization：如果赠予人未规定，允许受赠人发送可支配的最大代币金额，因此验证允许列表（AllowList）也非常重要，该列表指定受赠人可以向其发送代币的特定地址。

费用补助模块

另一个影响用户体验的障碍是区块链用户需持有多种原生代币以便与不同生态系统交互。这对初次接触各种存在于 Cosmos 生态系统的链条的非加密原生用户尤其影响整体用户体验。

然而，通过费补助模块的整合，这一障碍得到了突破。类似于以太坊上启用账户抽象的支付者合约，Cosmos 上的费用补助模块允许赠予人授予受赠人费用补助，支付部分或全部的交易费用。资金仍然在赠予人的控制之下，随时可以撤销补助。

费用补助类型

费用补助大致可分为两类：BasicAllowance（基本补助）和 PeriodicAllowance（定期补助）。

BasicAllowance 允许受赠人使用来自赠予人账户的费用，直至达到支出限额或到期时间。之后，补助将在状态中终止。需要注意的是，BasicAllowance 实现了一次性费用补助。如果支出限额和时间均为空，则不设到期和支出上限。

PeriodicAllowance 则允许费用补助在每个指定的时间段后定期续期。Period_spend_limit 指定了这一周期内所能支出的最大代币量。Period_reset 记录下一个周期应该发生的时间，period_can_spend 跟踪在新周期开始之前剩余的代币量。

理解操作框架

通过 AllowedMsgAllowance 为指定消息类型创建补助。补助可以是 BasicAllowance 或 PeriodicAllowance。如果设置了时间过期，费用补助将在状态中排队，过期前缀添加到补助的前面，而 Endblocker 会检查 FeeAllowanceQueue 状态中是否存在过期的授权，发现后进行修剪。除了 MsgGrantAllowance，费用补助也可以通过 MsgRevokeAllowance 进行撤销。

综合来看，Authz 和费用补助模块解锁了创新和多样化的用例，最终在 Cosmos 生态系统中构建出更好的用户体验。

结论

账户抽象 截至2024年5月27日，数据仅为估算值。

在现货 BTC ETFs 和 ETH ETFs 获得批准后，机构和零售需求显著增加，预示着将迎来一波渴望接触该行业的新用户。账户抽象将成为今年的重要叙述，因为协议和 DApp 们寻求创造无缝体验以扩展他们的社区。

免责声明

本文材料仅供一般信息参考，并不构成或应被解释为任何形式的研究成果、专业建议、请求、要约、推荐或交易策略。对于本文所提供的任何一般金融和市场信息、分析及/或观点的公平性、准确性、及时性、完整性或正确性，并不作出任何保证、声明、担保或承诺，无论是明示还是暗示，HashKey Capital 均不就使用或依赖该信息而承担任何责任或义务。本文的信息可能随时更改，恕不另行通知。本报告未经香港证券及期货事务监察委员会、新加坡金融管理局或香港或新加坡任何监管机构审核。

请注意，数字资产，包括加密货币，具有高度波动性和市场风险。数字资产的价值可能会显著波动，无法保证盈利或资本保护。你在做出任何决策之前，务必仔细考虑自身的风险承受能力和财务状况。

在某些法域内，报告的分发可能受到限制。本材料并不构成在没有授权的法域或向任何人分发该报告的请求或要约。

及时了解 HashKey Capital 最新动态 -

网站 — https://hashkey.capital/

Twitter — https://twitter.com/HashKey_Capital

LinkedIn — https://www.linkedin.com/company/hashkeycapital/

• 原文链接： medium.com/hashkey-capit...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～