从会话密钥到子账户：穿越迷思

智能钱包子账户如何通过强大的安全保障提供更出色的链上体验

子账户是一项新的智能钱包功能，可实现无缝的应用内体验。它结合了消费权限、分层账户所有权和一个新的 wallet_addSubAccount RPC。智能钱包子账户已准备就绪，供开发者在 Base 测试网上进行集成 —— 并将在第二季度在主网上线。

六个月前，我们开始使用 Session Keys 改进应用内交易，经过大量工作后，我们推出了子账户。本博客的目的是展示我们的工作，希望促进富有成效的讨论，并共同找到最佳解决方案。

Session Key 是智能账户上的一个签名者，具有有限的权限。例如，Session Key 可以配置为仅在一个小时内作为账户上的有效签名者，或者仅可以调用特定合约上的单个函数。

从我们开始研究智能钱包的早期，我们就对 Session Keys 感兴趣。它们经常出现：我们如何启用订阅支付？Session Keys。我们如何允许应用程序跳过某些低价值交易的交易弹窗？Session Keys。

但我们没有在 v1 中包含 Session Keys，因为我们仍然有很多关于如何安全使用它们的问题。在编写智能合约时，需要仔细考虑每个操作，以节省 gas。有效且安全地检查调用数据以强制执行每个签名者的配置的想法令人生畏。

在 v1 发布几个月后，我们开始了对 Session Keys 的认真研究，并在决定改变方法之前进行了一次外部审计。

我们使用 Session Keys 的历程

要求

我们对 Session Keys 的要求如下：

1. Session Key 应该可以配置为可能用于任何链上调用。为了让 Session Keys 允许用户在某些条件下跳过我们的交易弹窗，它们应该足够灵活，以服务于开发者想要进行的任何类型的链上调用。

2. Session Key 交易的顶级调用者应该是用户的账户：Session Key 交易应该像用户账户的其他任何调用一样出现在链上。

3. 我们必须能够清楚地向用户表达 Session Key 将被允许做什么，以便他们可以就是否批准给定的 Session Key 做出明智的决定。

4. 我们必须确保我们能够保证 Session Key 只能做我们告诉用户它能够做的事情。

状态

使用 Session Keys 安全性时首先想到的问题是 Session Key 可能滥用的现有链上状态。链上验证可能会筛选受限的函数名称（例如 transferFrom、approve）或受限的地址（例如 USDC 地址）。但链上验证实际上无法防范以下可能性：例如，用户的智能账户可能已经为具有 stealMyUSDC 函数的合约批准了 USDC，Session Key 可能会调用该函数。

作为一个更实际的例子，用户可能已经为 Uniswap 合约进行了现有批准，任何 Session Key 都可能滥用这些批准。

这里真正的问题是状态结合依赖于验证调用地址的逻辑，因为任何有价值的合约都只会在某个调用者说这样做时才使用其授权。例如，Uniswap 只允许 wilson.base.eth 调用以使用 wilson.base.eth 的授权。

我们通过要求所有 Session Key 调用都通过新的特定于应用程序的合约来解决此问题。如果一个应用程序希望用户调用某个合约 X，则来自该账户的调用必须首先通过某个特定于应用程序的合约 Y。这样，任何依赖于 msg.sender 的状态都不会被滥用。

此外，我们要求对这些特定于应用程序的合约的调用使用我们创建的新的函数选择器，以减轻 Session Key 可以直接调用现有重要函数的风险。

这简化了事情：每个 Session Key 只能用于调用单个特定合约，并且只能调用该合约上的单个函数选择器。如果开发者想要进行任意调用，则需要从该合约进行调用。

这种方法还允许我们避免尝试向用户显示合约地址或函数名称以供批准，这应该被视为来自要求 (3.) 的非启动项。不能指望用户推断函数名称或十六进制字符串之类的事情。

谁可以调用什么？

上述解决方案引入了一个新问题。假设 App A 请求一个 Session Key，并告诉我们它将通过合同 Y 路由调用。稍后，应用程序 B 也请求一个 Session Key，也通过合同 Y 路由调用。

用户可能已经在合同 Y 上累积了状态，甚至资产，他们信任 App A 调用合同 Y，如果 app B 可以使用相同的状态和资产，用户可能会感到惊讶。

所以现在我们需要引入一个关于控制证明的要求。App A 需要证明它是合约 X 的权威，然后它才能拥有可以调用合约 X 的 Session Key。

开发者体验正在显着降低。现在，为了使用 Session Keys，开发者需要 (1) 部署一个新合约，他们的 Session Key 调用将通过该合约进行代理，以及 (2) 管理一个作为该合约权限的密钥。

更多问题

在 ERC-4337 的上下文中，仍然存在更多问题。现有状态可以在验证阶段被滥用。例如，如果用户已批准 ERC-20 paymaster 花费其 USDC，则任何 Session Key 都可能滥用此权限：从用户帐户创建垃圾邮件调用，直到整个 USDC 批准耗尽。如果攻击者也可以充当 bundler，他们可能会从中获利。

所以，现在我们需要 paymaster 限制。Session Keys 能否不使用任何 paymaster？这将再次降低开发者体验。他们只能使用某些 paymaster 吗？如何决定和更改此设置，以及如何将所有这些信息传达给用户？

Co-signers 和 Offchain Simulation

请注意，如果你可以接受引入链下 co-signer，它也必须签署所有 Session Key 请求，则可以回避许多这些问题。其思想是，co-signer 服务运行请求的某些链下模拟，将状态差异与 Session Key 应该允许执行的操作进行比较，并批准或拒绝。

可能有很多很棒的服务可以朝这个方向构建，但这风险很高：一个错误，用户可能会损失所有资金。它对用户来说也是不透明的，并且可能允许拒绝服务审查。最后，它不是链上的，因此不容易与其他系统组合。

到达子帐户

学会喜欢应用程序帐户

使用我描述的解决方案，我们创建了一种准应用程序帐户：有一个合约，来自用户帐户的 Session Key 调用必须通过该合约进行代理。此合约是特定于应用程序的，应用程序必须证明对其的控制权。但是，如上所述，我们仍然存在问题。这些问题主要源于要求 (2.)：顶级调用者必须是用户的帐户。

我们退后一步问自己，“如果我们放宽此约束并接受应用程序帐户怎么办？”应用程序帐户由开发者控制，可用于任意调用，并且他们已经拥有许多团队提供的出色工具。为了增强它们的能力，我们需要一种方法，让应用程序帐户 (A) 使用来自用户通用帐户的资金和 (B) 使用户感觉它们是其通用帐户的一部分。

消费权限

为了完成 (A)，我们创建了 消费权限，该权限于 12 月份推出。消费权限允许“spender”根据某些规则从用户智能钱包中提取资金，例如，消费权限可以编纂“0x1 可以在一年内每周花费 10 个 USDC。”用户可以随时取消消费权限。

消费权限没有与 Session Keys 相同的安全问题，因为它们不像 Session Keys 那样开放。调用由消费权限管理器合约验证，该合约只能向用户帐户发出非常特定格式的请求。

消费权限也很容易被其他团队采用，因为管理器合约仅要求该帐户实现 ERC-1271（所有智能帐户都应实现），并且消费权限可以使用现有的 ERC-712 格式由用户签名，所有钱包均已支持该格式。

子帐户

现在我们正在承担使应用程序帐户感觉像是用户通用帐户的一部分的任务。这可以通过以下方式实现：

1. 分层智能帐户所有权：用户的通用钱包可以拥有其应用程序帐户，从而解锁统一管理，通用帐户可以在应用程序帐户上移动资产。Vitalik 在他 最近的博客文章 中提到了这个想法：“但是，许多应用程序钱包的用户应该能够将他们所有的钱包链接在一起，这样他们就只有一个‘访问控制’需要担心。最简单的方法是分层方案，其中有一个快速的“链接”过程，允许用户将其主钱包设置为所有应用程序内钱包的监护人。”

2. 使通用帐户了解应用程序帐户的一种方法。这可以通过新的 wallet_addSubAccount RPC 实现。它允许应用程序请求钱包将新地址作为用户通用帐户的一部分进行跟踪，并假定传递的帐户归通用钱包所有，即是“子帐户”。

将所有这些结合在一起，我们最终得到类似于我们的 Session Key 方法的东西，但我们认为它更灵活、更安全。

当子帐户与消费权限结合使用时，我们相信我们可以为我们提供 Session Keys 的所有 UX 收益，并具有更好的开发者体验和用户安全保证。

关系的可视化

我们还认为，接受多地址帐户和地址层次结构（现在可以在链上进行编纂，智能帐户拥有其他智能帐户）可以显着改善当今加密货币中的用户体验，其中许多用户的资金分散在许多地址中，并且没有简单的方法来跟踪或控制它们。

开始构建

使用这些工具，开发者可以为用户配置 AI 助手，这些助手拥有自己的孤立智能帐户，能够使用细粒度的权限进行消费，并且能够从用户的通用钱包进行监控和控制。开发者可以构建链上游戏体验，用户可以通过一次性消费权限开始游戏，此后无需弹出窗口即可进行交易，并将游戏内资产积累到用户可以从其通用帐户控制的地址。这些只是一些例子。我们迫不及待地想看看开发者会想出什么。查看我们的 文档 以开始使用。

我们渴望听到你对此的所有反馈，并很高兴与你一起构建！

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