账户抽象的关键

本文探讨了账户抽象(Account Abstraction, AA)如何提升区块链用户体验,强调它不仅仅是简化交易费用和批量交易。文章分析了不同关键管理系统的优缺点,指出传统的 12 个单词的密钥存储存在安全隐患,且难以教育用户安全存储私钥。AA 允许多密钥和可编程访问控制,提高了安全性。

图像

每个人都在谈论账户抽象(AA)及其对区块链领域用户体验的潜在革命性影响。然而,对于 AA 的主要误解是,它不仅仅是抽象化 gas 费用或实现批量交易。如何实现?通过可编程的密钥管理系统。

这些系统可以为日常设备提供硬件级别的安全性,并将 Web2 身份验证方法整合到 Web3 环境中,使我们能够超越传统的 12 个单词种子短语。今天,我将解释开发者可以利用的不同密钥管理系统,以及它们最有用的特定用例。

超越 12 个单词

我们的行业喜欢流行词,“无种子”是最近吸引注意力的词汇之一。虽然我们都同意,期望用户安全存储他们的私钥是不现实的,并且导致了数百万美元的损失,但问题仍然存在:如果我们不向用户展示种子短语,我们该在哪里存储密钥?

在没有账户抽象(AA)的时候,大多数现有的解决方案依赖于多方计算(MPC)将密钥分散成多个部分,并创建一个阈值来进行交易。这些解决方案通常声称是自我托管。然而,这并不完全准确。例如,币安存储一个密钥的部分,充当在用户丢失设备时的保管方。这种设置意味着,尽管有这样的说法,用户实际上并不真正控制他们的密钥,并且在密钥恢复上仍然依赖于一个中心化实体。

图像

此外,如果任何密钥部分被泄露,就无法从主账户撤销密钥。撤销是不可能的,因为外部拥有账户(EOA)不支持密钥轮换,这意味着被泄露的密钥始终都是账户的一部分。这带来了重大的安全风险,因为被妥协的密钥无法被替换或移除,使账户在无限期内处于脆弱状态。

如果你想了解更多关于 AA 如何为可编程账户和密钥轮换铺平道路的信息,你可以

查看我的文章

1. 完全可编程的账户:账户抽象

账户抽象允许开发者构建不同的密钥管理系统。一个账户可以通过多个密钥和不同的身份验证方法进行控制,所有这些都支持密钥轮换。更好的是,密钥的权力可以被区分。这意味着用户可以对同一个账户使用不同的密钥,每个钥匙针对不同的用例量身定制。我将稍后详细解释这些用例。

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

  1. 第一部分是验证,在链上验证账户所有权。

  2. 第二部分是执行,执行消息。

这两个部分都是完全可编程的;例如,你可以定义两个密钥(i,ii),第一个密钥(i)可以执行即时交易,而第二个密钥(ii)仅能在时间锁定后执行交易。这意味着我们可以定义密钥的权力,添加时间锁定或启用其他条件来执行交易。因此,当我们谈论传统账户(EOA)时,身份验证等同于授权。使用 AA,授权是可编程的,因此开发者可以定义基于角色的访问控制方案并执行最小权限原则。

在加密空间中,有许多身份验证方法(即密钥管理系统)可以启用基于角色的访问控制方案,仅使用一个密钥并不能解决与密钥管理相关的所有问题。密钥管理系统中最重要的方面是:密钥的存储位置和谁进行身份验证。

不同密钥管理系统的优缺点

我将快速总结Passkeys(消费者安全隔离区)、基于 MPC 的解决方案、基于云的 TEE 解决方案、保管解决方案、传统 12 个单词和会话密钥。之后,将解释最佳组合。

1. 传统 12 个单词 - (secp256k1)

比特币和以太坊支持 secp256k1

ECC(椭圆曲线密码学)算法来创建私钥并将其存储在用户的设备上。这种方法广泛用于 EOA,也可以应用于智能账户 。使用此方法,钱包应用程序通过随机密钥生成算法生成一个私钥,然后将私钥存储在共享存储中。

使用 secp256k1 有几个优点:没有额外的 gas 费用,成本低,并且可以通过 ecrecover 预编译轻松在链上验证。它也是自我托管的,因为只有用户可以访问该密钥。

然而,也有一些缺点:

  1. 教育用户在丢失设备的情况下如何安全存储他们的密钥是一个挑战。

  2. 木马或恶意软件可能会从用户的设备上窃取私钥,因为它存储在共享存储中。

NIST 不支持 secp256k1 曲线,这意味着它不被流行框架和大多数硬件广泛支持。

图像

2. Passkeys(消费者安全隔离区)

几乎所有现代设备都有两个主要组件:操作系统(带有相关的共享存储)和安全隔离区。操作系统处理大多数操作,除了保护生物识别数据、加密密钥、加密以及设备解锁等敏感任务。

开发者创建了一个专用的微芯片,称为安全隔离区,以单独管理这些敏感操作。安全隔离区的功能类似于硬件钱包;它独立运行,安全处理敏感数据,甚至设备所有者也无法访问其内容。幸运的是,安全隔离区支持加密操作,例如创建私钥和用其签署消息。不幸的是,安全隔离区不支持以太坊支持的曲线(secp256k1),而是支持 p256 曲线。为了启用本地 P256 验证,我们( @getclave 团队)提出了 RIP-7212 ,现在几乎所有主要的 rollups 都支持它。

安全隔离区的最大优势在于我们可以通过生物识别身份验证在安全隔离区内创建一个私钥,从而实现一键式入驻体验,并在现代设备上提供最佳的安全性——硬件级别。然而,它也有一些缺点:

  • 在没有 RIP-7212 的情况下,P256 验证昂贵且增加了漏洞风险。

  • 由于密钥无法提取,因此可恢复性在此缺失(Passkeys允许有限的恢复,但仍不足够)。

  • 如果Passkeys或安全隔离区(SE)应用的网页域名停止工作,用户将无法访问私钥,因为安全隔离区被设计为隔离和独立的。没有相关的应用程序或网页域,无法检索或与私钥交互,导致用户无法执行必要的加密操作。我会解释如何解决这个问题。

图像

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

SSS(Shamir's Secret Sharing)解决方案创造了一种消除传统密钥管理系统单点故障的方法。它们本质上将密钥拆分为不同的部分,并建立一个访问密钥的门槛。通过分发这些部分,SSS 确保没有单一实体持有整个密钥,从而增强了安全性。

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

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

大多数 MPC 解决方案需要一个中心化的方,有时候它们所称的去中心化并不是真正的去中心化。带有 AA 的 MPC 很强大,因为密钥轮换是可能的,但许多 MPC 解决方案在某种功能上包括一些阈值控制。此外,在许多情况下,即使在轮换后,先前的密钥可能仍然会被使用,因此人们需要信任这些密钥确实被处理掉了。一些 MPC 解决方案可以审查用户,因此仅仅依赖 MPC 并不总是可行。SSS 的另一个主要缺点是它在浏览器中重建私钥。明文密钥在客户端可用是一个巨大的安全风险。TSS 从不重建密钥,而是使用 MPC 在密钥份额之间进行签名。

MPC

4. 基于云的 TEE 解决方案

我认为基于云的可信执行环境(TEE)和基于 SSS 的解决方案并没有太大不同,但我仍然想解释它们是如何工作的。可信执行环境的功能正如其编码所描述的那样;它们是不可变的(至少它们声称是),而 TEE 甚至不会向 TEE 所有者显示内部内容。它们旨在以完整性运作——即使没有人监视,它们也能做正确的事情。因此,只要 TEE 正常工作,密钥就不会暴露给客户端。

通过利用 TEE,我们可以构建密钥管理层,开发人员可以使用不同的身份验证方法,TEE 可以验证这些方法。验证后,TEE 使用与用户关联的私钥签署一条消息并在链上进行验证。

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

基于云的 TEE 从理论上看是有前途的,但在过去,我们在云 TEE 中见过诸如 sgx.fail 的漏洞。然而,TEE 的优势在于,即使存在后门或漏洞,攻击者也需要对 TEE 进行物理访问,这就是消费者硬件(安全区 - 密码)如此强大的原因,因为消费者硬件将密钥存储在用户的安全区内,只有所有者可以访问该密钥,而云 TEE 将密钥存储在云中,使其容易受到攻击。

image.png

不是你的安全区,也不是你的币。

正如我提到的,TEE 有一些优势,比如使用几乎所有身份验证方法而没有任何密码学阻碍。然而,它们也有一些缺点:

如果服务提供商关闭服务器,用户的资金将被冻结,没人可以访问它们。密钥存储在云 TEE 中,这意味着它们可以审查用户。仅依赖 TEE 进行密钥管理会创建一个单点故障。

图像

会话密钥:有限权限的新方式

我们谈到了永久密钥。如果我们可以生成一个临时密钥,具有有限的资产访问权限,并在用户决定后消失呢?会话密钥允许我们做到这一点:

在 web2 世界中,会话密钥就像在两个设备(例如你的计算机和服务器)之间对话时使用的临时密码。它们在对话开始时创建,用于保护共享的信息,随后在对话结束后被丢弃。因此,即使黑客以某种方式发现了这个密码,他们也无法用它来监听未来的对话,因为每次都会创建新的、不同的密码(或会话密钥)。

在 Web3 世界中,我们定义会话密钥为一种框架,它有可能改变用户与 dApp 的交互方式。会话密钥的目标是让用户可以在各种场景中设置特定时间的预批准,并无需签名进行交易。但它是如何工作的呢?

用户创建一个有限权限的会话密钥,可以仅如用户指定的那样花费资产,仅在有限的时间内,并且可以随时撤回。在此之后,后端服务允许用户通过代签交易来进行交易。这种设置在 dApp 和用户之间创建了一个临时的信任窗口。它比无限批准更好,因为用户给予的批准仅限于特定资产且在定义的期间内。即使 dApp 被黑客攻击,用户也不需要担心几个月前生成的会话密钥🙂。

图像

不同用例的最佳身份验证与密钥管理组合

我已经解释了不同的密钥管理系统及其优缺点。通过 AA 的力量,我们可以结合这些密钥管理系统,创建强大的结构,最小化折衷。让我们解释一下 C.1)Passkey + 带时间锁的恢复 - Clave - 一个存储有价值资金的金融科技应用。

安全区Secure Enclave(Passkeys)基于硬件的身份验证方法提供硬件级别的安全性;然而,它们的可恢复性对于大多数用户来说往往不足。幸运的是,AA 允许开发人员结合不同的签名方法并在一个帐户中使用它们。通过将恢复签名者添加到智能账户,我们可以解决 Passkeys 存在的可恢复性问题。

有几种恢复选项,例如社交恢复、通用恢复(基于 ZK 邮件的恢复)和基于 MPC 的恢复。然而,在我看来,对于设计为完全自我托管的金融科技应用,社交恢复解决了大多数问题。在 Clave,我们构建了一个社交恢复模块,并正在开发通用恢复。

这种方法最大化了安全性,这对于金融应用是极好的。但它有一个重要的缺点:该应用要求用户在每次交易时进行生物识别认证。想象一下,你想在社交媒体应用中分享内容,而应用程序弹出了生物识别签名界面……可怕吧?

图像

非金融应用,如社交金融应用和去中心化游戏,需要一种更简单的交易方式,理想情况下不需要用户对每笔交易进行签名。怎样呢?答案就是:

1. Passkey + 具有时间锁的恢复 + 会话密钥 — 移动社交应用

会话密钥使用户能够在没有签名界面的情况下进行交易。基于 NFT 的游戏或社交应用可以继承会话密钥,以便临时且有限地访问用户的资产。如果你认为这增加了额外的信任假设,让我们解释一下今天的前端是如何工作的:

今天,大多数用户甚至在玩游戏或与 dApp 互动时都不会检查他们正在签署的内容。这是危险的,因为恶意的前端可能导致用户失去所有资产。

Twitter: every attack in a game as a blockchain transaction

会话密钥是一个更好的替代方案。用户可以检查会话将持续多长时间以及会话可以访问哪些资产,从而减少对 dApp 的信任需求。在会话时间到期后,用户不需要担心批准 = 不再需要

revoke.cash

这样的应用 :)

2. MPC 或基于云的 TEE 签名者 + 自助保管签名者用于逃避

MPC 或基于云的 TEE 的第三方密钥管理层的缺点是大多数不是自助保管的,并且有显著的中心化组成部分。然而,一些 dApp 需要内嵌钱包而没有额外的 gas 开销,因此需要 MPC 或基于云的 TEE 的解决方案。为“愤怒退出”添加额外的签名者可以解决这些密钥管理系统所面临的审查问题,还可以减轻这些 dApp 可能面临的潜在法律问题。你需要一个智能钱包来构建这一点,因为使用 EOA 不可能进行密钥轮换。

已经有几个应用程序使用这种密钥管理架构。

3. 12 个单词 + 硬件签名者以实现最大安全性 — DeFi 浏览器扩展体验

DeFi 用户喜欢浏览器扩展体验,更改用户行为是现代世界中最难的事情之一。那么,为什么不构建一个更好的替代方案呢?将硬件签名者(安全隔离区或密钥签名器)与通过扩展访问的 12 个单词种子短语结合起来,也可以解决泄露私钥的问题。这种方法提高了安全性,同时无需改变用户的行为。在 AA 领域的几个团队正在努力实现这一目标。(例如 @myBraavos )

智能账户不够智能

想象一下,你是一个用户,首先生成了一个 EOA,使用@MetaMask 然后发现了一个像 Zerion 的替代方案。你决定使用 @zerion ,你所需要做的就是导入你的种子短语——很简单。现在,想象一下在 Starknet 上做同样的事情,那里所有的钱包都是智能账户。你无法做到,因为 Braavos 和 Argent 不兼容。这个问题在 EIP-4337 生态系统和 @zkSync 的原生 AA 中也存在。

我们需要标准(而非看门人),或者至少需要更好的方法来资助新钱包。否则,智能钱包将永远无法广泛采用,现有参与者将继续成为决策者,支配行业实践,即使它们并不正确。

此外,“愤怒退出”应该是默认功能,因为几乎所有密钥管理系统中的中心参与者都可以被关闭。用户更改签名者或切换智能合约应该更容易,自托管应该是用户的默认选项。当前有两个模块化智能账户标准:ERC-6900 和 ERC-7579。它们都试图实现一个相似的目标——使智能账户更智能。

图像

特别感谢 DerekKonrad以及Noam 的反馈和评论!

作者:@DoganEth

并之前发表在这里

如需更全面和深刻的以太坊及更广泛的加密领域研究,请访问 2077 Research

我是 AI 翻译助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~

点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
2077 Research
2077 Research
https://research.2077.xyz