随着账户抽象（Account Abstraction, AA）成为区块链领域的热门话题，许多人都在谈论它如何革新用户体验。然而，关于AA的一个常见误解是，它不仅仅是抽象化燃气费用或启用批量交易。那么，它究竟是如何实现这一目标的呢？答案在于：可编程的密钥管理系统。

这些系统可以为日常设备提供硬件级别的安全保护，并将Web2的认证方法无缝集成到Web3的环境中，让我们能够摆脱传统的12词种子短语。今天，我将深入介绍几种开发者可以利用的密钥管理系统，并讨论它们在不同应用场景中的最佳使用方式。

超越12个词

在区块链行业，我们常常被流行词汇吸引，最近“无种子（seedless）”成为了一个热门话题。虽然大家普遍认同，让用户自己保管私钥是不切实际的，而且已经导致了数百万美元的损失，但一个问题仍然存在：如果我们不再让用户保存种子短语，那该如何存储密钥？

在没有账户抽象（AA）机制的情况下，大多数现有的解决方案依赖多方计算（MPC）技术，将密钥分割成多个部分，并设置一个阈值来执行交易。这些方案通常声称是“自托管”的，但这并不完全准确。举个例子，像Binance这样的平台会存储密钥的一部分，充当“托管方”，以防用户丢失设备。虽然这些服务宣称用户可以自主管理密钥，但实际情况是，用户并没有完全控制自己的密钥，仍然需要依赖中心化的实体来恢复密钥。

此外，如果任何密钥部分被泄露，就无法撤销或更换该密钥。由于外部拥有账户（EOA）并不支持密钥轮换，一旦密钥泄露，它将永远与账户绑定，无法移除或替换。这带来了巨大的安全隐患，因为一旦密钥泄露，账户将始终处于易受攻击的状态。

如果你想深入了解账户抽象如何为可编程账户和密钥轮换提供解决方案，可以查看我的相关文章。

1. 完全可编程账户：账户抽象

账户抽象（Account Abstraction, AA）使开发者能够构建不同的密钥管理系统。一个账户可以通过多个密钥和不同的认证方法进行控制，并且支持密钥轮换。更重要的是，密钥的权限可以被区分开来。这意味着用户可以为同一个账户使用不同的密钥，每个密钥可以根据不同的使用场景进行定制。我将在稍后详细解释这些使用场景。

通过AA，资金存储在智能合约中，账户的所有权由这些智能合约定义。兼容EIP-4337的账户在交易中有两个部分：

第一部分是验证（Verification），在链上验证账户的所有权。

第二部分是执行（Execution），执行消息。

这两个部分都是完全可编程的；例如，你可以定义两个密钥（i、ii），其中第一个密钥（i）可以执行即时交易，而第二个密钥（ii）只有在时间锁定后才能执行交易。这意味着我们可以定义密钥的权限、添加时间锁或启用其他条件来执行交易。

因此，当我们谈论传统账户（EOA）时，认证等同于授权。而在AA中，授权是可编程的，开发者可以定义基于角色的访问控制（RBAC）方案，并执行最小权限原则。

在加密领域，存在许多能够启用基于角色的访问控制方案的认证方法（即密钥管理系统），而仅使用一个密钥无法解决与密钥管理相关的所有问题。密钥管理系统的最重要方面包括：密钥存储的位置和谁来进行认证。

密钥管理系统的优缺点

我将快速总结以下几种密钥管理系统：Passkeys（消费者安全隔离区）、基于MPC的解决方案、基于云的TEE解决方案、托管解决方案、传统12词种子短语和会话密钥。之后，我将解释最佳的组合方案。

1. 传统12词种子短语 - （secp256k1）

比特币和以太坊使用secp256k1椭圆曲线加密（ECC）算法来创建私钥，并将私钥存储在用户的设备上。这种方法在外部拥有账户（EOA）中广泛应用，也可以应用于智能账户。使用这种方法时，钱包应用会通过随机密钥生成算法生成私钥，然后将私钥存储在共享存储中。

优点：

• 无额外燃气费用：使用secp256k1算法不会产生额外的燃气费用，且交易成本低。
• 易于链上验证：通过ecrecover预编译，验证过程简单。
• 自托管：密钥只由用户自己访问，无需依赖第三方。

缺点：

• 用户教育难度大：由于用户需要安全存储私钥，一旦设备丢失会造成问题，教育用户如何安全存储密钥是一大挑战。
• 可能被恶意软件盗取：由于私钥存储在共享存储中，木马或恶意软件可能从用户设备中窃取私钥。
• 缺乏广泛支持：NIST（美国国家标准与技术研究院）不支持secp256k1曲线，这意味着它并不被大多数主流框架和硬件广泛支持。

2. Passkeys（消费者安全隔离区）

几乎所有现代设备都有两个主要组件：操作系统（以及相关的共享存储）和安全隔离区（Secure Enclave）。操作系统负责处理大多数操作，但敏感任务如保护生物识别数据、加密密钥、加密以及设备解锁等则由安全隔离区处理。

开发者为管理这些敏感操作专门创建了一个名为安全隔离区的微芯片。安全隔离区的功能类似于硬件钱包；它独立运行，安全地处理敏感数据，甚至设备所有者也无法访问其中的内容。幸运的是，安全隔离区支持加密操作，例如创建私钥并用它们签署消息。不幸的是，安全隔离区不支持以太坊所使用的曲线（secp256k1），而是支持p256曲线。为了启用原生P256验证，我们（@getclave团队）提出了RIP-7212标准，现在几乎所有的大型rollup都已支持这一标准。

安全隔离区的最佳部分是，我们可以仅通过生物识别认证在安全隔离区内创建私钥，从而实现一键式入门体验，并提供现代设备上最佳的安全性——硬件级别的保护。然而，它也有一些缺点：

• 没有RIP-7212的P256验证代价高昂，且增加了漏洞风险：在没有RIP-7212的情况下，P256验证会变得昂贵，并且增加了发生漏洞的风险。
• 无法提取密钥，导致缺乏恢复性：由于密钥无法被提取，恢复密钥的功能缺失（Passkeys提供有限的恢复功能，但仍不足够）。
• 如果Passkey的Web域名或安全隔离区（SE）应用停止工作，用户将无法访问私钥：由于安全隔离区被设计为隔离和独立的，没有关联的应用或Web域名时，无法检索或与私钥交互，导致用户无法执行必要的加密操作。

接下来，我将解释如何解决这个问题。

3. 基于SSS的密钥管理解决方案

SSS（Shamir的秘密共享）解决方案通过消除传统密钥管理系统中的单点故障，为密钥管理提供了一种新方式。它们将密钥分割成不同的部分，并设定一个门槛来访问密钥。通过分发这些密钥部分，SSS确保没有单一实体持有完整的密钥，从而增强了安全性。

让我们看看它们是如何存储密钥以及如何达到访问私钥所需的法定人数。大多数现有的协议使用三个密钥份额：一个份额存储在用户设备上，一个存储在其服务器（或MPC网络内），还有一个作为备份保留。有些应用程序，如Google Drive，利用云存储解决方案来存储这些密钥份额。

因此，用户将他们的钱包控制权委托给多个有法定人数的其他方。MPC（多方计算）在将密钥管理职责委托给不同方时非常强大，但它也有一些缺点：

• 许多MPC解决方案依赖于中心化的实体，有时它们所称的去中心化并不完全去中心化：MPC与AA结合非常强大，因为密钥轮换是可能的，但许多MPC解决方案包含某些功能来进行门控。
• 即使在密钥轮换后，之前的密钥可能仍然被使用，因此必须信任这些密钥已被安全销毁：某些MPC解决方案可能会审查用户，因此单纯依赖MPC并不总是可行的。

SSS的另一个主要缺点是，它通常会在浏览器中重建私钥。这对于纯文本密钥在客户端可用来说是一个巨大的安全风险。与此不同，TSS（阈值签名方案）从不重建密钥，而是使用MPC将签名分布到多个密钥份额中。

4. 基于云的TEE解决方案

我认为基于云的可信执行环境（TEE）和基于SSS的解决方案并没有太大的不同，但我仍然想解释一下它们的工作原理。可信执行环境的功能完全取决于其编码方式；它们是不可变的（至少声称是不可变的），即便是TEE的拥有者也无法查看其中的内容。它们的设计目标是确保完整性——即使没有人监督，它们也会做出正确的决策。因此，只要TEE正常工作，密钥就永远不会暴露给客户端。

通过利用TEE，我们可以构建密钥管理层，开发者可以使用不同的认证方法，而TEE则可以验证这些方法。在验证之后，TEE会使用与用户关联的私钥签署消息并在链上进行验证。

控制用户资金的主要私钥存储在TEE内，且无法提取。这对去中心化构成威胁，因为如果服务商决定关闭或审查用户，dApp开发者无能为力。

基于云的TEE在理论上看起来很有前景，但过去我们也曾见过像sgx.fail这样的漏洞存在于云TEE中。然而，TEE的优势在于，即便存在后门或漏洞，攻击者也需要对TEE进行物理访问，这就是为什么消费者硬件（如Secure Enclave - Passkeys）如此强大的原因，因为消费者硬件将密钥存储在用户的Secure Enclave内，只有所有者才能访问密钥，而云TEE则将密钥存储在云端，这使得它容易受到攻击。

正如我之前提到的，TEE有一些优势，比如可以使用几乎所有的认证方法，而不会受到加密障碍的限制。但它们也有一些缺点：

• 如果服务提供商关闭服务器，用户的资金将被冻结，且无法访问：密钥存储在云TEE内，这意味着服务提供商可以审查用户。仅依赖TEE进行密钥管理会产生单点故障的问题。

会话密钥：一种新的有限权限方式

我们已经讨论了永久密钥。那么，如果我们能够生成一个临时密钥，具有对资产的有限访问权限，并在用户指定的时间后消失呢？会话密钥让我们能够实现这一目标：

在Web2世界中，会话密钥类似于在两台设备之间（如计算机和服务器）通信时使用的临时密码。它们在会话开始时创建，用于保持共享信息的安全，随后在会话结束后被丢弃。因此，即使黑客设法得知这个密码，他们也无法用它来监听未来的对话，因为每次都会创建一个新的、不同的密码（或会话密钥）。

在Web3世界中，我们将会话密钥定义为一种潜在的框架，可以改变用户与去中心化应用（dApp）的交互方式。会话密钥的目标是允许用户在不同场景中为特定时间段设置预先授权，并且在不需要签署的情况下进行交易。那么，它是如何工作的呢？

用户可以创建一个有限权限的会话密钥，该密钥仅能按照用户指定的方式使用资产，且仅在限定的时间内有效，并且可以随时撤销。之后，后端服务允许用户代表他们签署交易，从而进行交易。这种设置在dApp与用户之间创建了一个临时的信任窗口。这比无限期授权要好得多，因为用户所授予的授权仅限于特定资产并且在定义的时间内有效。即使dApp被黑客攻击，用户也无需担心几个月前创建的会话密钥 🙂。

不同用例的最佳认证与密钥管理组合

我已经解释了不同的密钥管理系统及其优缺点。借助AA（账户抽象）的强大功能，我们可以将这些密钥管理系统结合起来，创建强大的结构，并尽量减少折衷。现在，让我们来解释一下不同的组合，首先是C.1) Passkey + 定时锁定恢复 - Clave - 一个存储贵重资金的金融应用。

基于Secure Enclave（Passkey）的认证方法提供了硬件级安全性；然而，它们的恢复能力对于大多数用户来说通常不足。幸运的是，AA允许开发者将不同的签名方法结合在一个账户中使用。通过向智能账户中添加一个恢复签名者，我们可以解决Passkey所面临的恢复问题。

有几种恢复选项，如社交恢复、通用恢复（基于ZK-Email的恢复）和基于MPC的恢复。然而，依我个人看法，对于设计为完全自托管的金融应用，社交恢复可以解决大多数问题。在Clave，我们构建了一个社交恢复模块，并正在开发通用恢复功能。

这种方法最大化了安全性，非常适合金融应用。但它也有一个重要的缺点：应用程序需要为用户每次交易进行生物识别认证。试想一下，当你在社交媒体应用中想分享内容时，应用弹出了生物识别认证界面…是不是觉得很糟糕？

像社交金融（Social-Fi）应用和去中心化游戏这样的非金融应用需要一种更简单的方式来进行交易，理想情况下无需用户每次都签署交易。如何实现呢？以下是答案：

1. Passkey + 定时锁定恢复 + 会话密钥 — 移动社交应用

会话密钥使用户能够在不需要签名界面的情况下进行交易。基于NFT的游戏或社交应用可以利用会话密钥来临时并有限地访问用户的资产。如果你认为这增加了额外的信任假设，接下来我们来解释一下今天的前端是如何运作的：

如今，大多数用户甚至不会检查他们在玩游戏或与dApp交互时所签署的内容。这是非常危险的，因为恶意的前端可以让用户失去所有资产。

会话密钥是一个更好的替代方案。用户可以查看会话将持续多长时间，以及会话可以访问哪些资产，从而减少对dApp的信任需求。在会话时间到期后，用户不再需要担心授权问题 —— 不再需要像revoke.cash这样的应用程序了 :)

1. 基于MPC或云TEE的签名者 + 自托管签名者（用于退出机制）

基于MPC或云TEE的第三方密钥管理层的缺点是，大多数情况下它们并非自托管，并且包含大量的集中化组件。然而，一些dApp需要嵌入式钱包且不增加额外的gas费用，因此需要MPC或云TEE解决方案。通过为“愤怒退出”添加额外的签名者，可以解决这些密钥管理系统面临的审查问题，同时减轻这些dApp可能面临的潜在法律问题。因为EOAs无法实现密钥轮换，所以你需要一个智能钱包来构建这个方案。

目前已经有一些应用程序采用了这种密钥管理架构。

1. 12个词 + 硬件签名器以最大化安全性 — DeFi浏览器扩展体验

DeFi用户热衷于浏览器扩展体验，而改变用户行为是现代世界中最难做到的事情之一。那么，为什么不构建一个更好的替代方案呢？将硬件签名器（如Secure Enclave或Passkey Signer）与通过扩展访问的12个单词种子短语相结合，也可以解决泄露私钥的问题。这种方法在提高安全性的同时，无需改变用户的行为。AA行业中的一些团队正在努力实现这一目标。（例如：@myBraavos）

智能账户还不够智能

想象一下，你是一个用户，首先在 @MetaMask 上生成了一个 EOA（Externally Owned Account），然后发现了像 Zerion 这样的替代品。你决定使用 @zerion，所有需要做的就是导入你的种子短语——非常简单。现在，想象一下如果你在 Starknet 上尝试做同样的事情，所有的钱包都是智能账户。你无法这么做，因为 Braavos 和 Argent 之间并不兼容。这个问题同样存在于 EIP-4337 生态系统以及 @zkSync 的原生 AA 中。

我们需要标准（而不是守门人），或者至少需要一种更好的方式来为新钱包提供资金。否则，智能钱包就无法得到广泛应用，现有的参与者将继续主导决策，制定行业实践，即使它们并不完全正确。

此外，“愤怒退出”应该是一个默认功能，因为几乎所有密钥管理系统中的中心化角色都可能被关闭。用户应该更容易更改签名者或切换智能合约，并且自托管应该是用户的默认选择。目前有两个模块化智能账户标准：ERC-6900 和 ERC-7579。它们都在尝试实现相似的目标——让智能账户变得更加智能。

特别感谢 Derek、Konrad 和 Noam 的反馈和评论！

声明：

1. 本文转载自【X】，著作权归属原作者【2077Research】，如对转载有异议，请联系 Gate Learn 团队，团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由 Gate Learn 团队翻译， 除非另有说明，否则不得复制、传播或抄袭经翻译文章。