一文读懂前沿的密钥管理解决方案和代表性的钱包。

撰文：Rui，SevenX Ventures

TL;DR

私钥是在以太坊上签署交易的关键所在，但即便是以助记词（也称「种子短语」） 这种可读形式进行管理，用户的私钥管理也是一场噩梦。而我们深知，将区块链变成一个复杂游戏从来都不是我们的本意。

要保证交易安全，就必须要对授权用户进行身份验证。随着互联网安全和用户体验的发展，我们已经从密码验证发展为面部识别和指纹等生物特征识别技术。在这一进展中，WebAuthn 是一个关键里程碑。本文将重点讨论三个术语：

• WebAuthn：这是一项 Web 身份验证标准，使用通常由外部验证器创建的基于公钥的凭证。无需密码，也可实现安全的用户身份验证。
• Secure Enclave：计算设备内基于硬件的安全区域，旨在保护敏感数据。Secure Enclave 的不同版本适用于 iOS、Android 和 Windows 设备。应用 WebAuthn，它可以作为外部验证器，带来硬件级别的安全系数，但是由于私钥绑定本地，这会使跨设备操作变得困难。
• Passkey：操作系统级别的 WebAuthn 应用，各种设备和系统提供商有其定制规则。例如，Apple 的 Passkey 利用 iCloud 钥匙串 (Keychain) 中存储的密钥进行跨设备同步。然而，这种方法通常只应用于特定的平台或系统，无法实现跨系统（Apple-Android)。

正如上文所述，WebAuthn 部署与我们对于日常区块链用户的目标是一致的，即实现高级防钓鱼安全和用户友好的体验。以下是将 WebAuthn 实现融入到区块链中的提议：

• 密钥层：用户可以使用面部识别或指纹等丝滑方法进行身份验证。从底层来看，它是基于硬件的安全处理器（如 Secure Enclave）或云服务（如 iCloud 和 Google Cloud）处理密钥管理的。后面我将深入讨论跨设备和跨平台问题。
• 账户层：智能合约账户（SCA）可分配任意签名者（例如 SE 和 Passkey）和阈值机制。此外，其模块化设计增强了灵活性和可升级性。例如，智能合约账户可以根据交易数量、时间或 IP 地址等因素动态调整其签名要求。另一方面，传统的外部账户（EOA）可以通过多方计算 (MPC) 服务进行扩展，相比于智能合约账户，这种组合提供了更好的互操作性和成本效益，但不具备智能合约账户提供的高级功能，特别是密钥轮换会更加有挑战。
• 签名层：以太坊原生支持 k1 曲线，但 WebAuthn 的签名验证会产生更高的成本，因为它使用 r1 曲线生成密钥。因此，zkSync 等 Layer 2 解决方案计划采用原生 EIP-7212 r1 曲线的预编译。此外，还有第三方服务、Solidity 验证器、零知识（ZK）验证器和分布式密钥管理系统，都能以更具成本效益的方式方便 r1 曲线签名。

* 免责声明：

技术进步并不代表一定能在市场上获得成功；并非所有设备和平台都采用了 Passkey；使用智能合约账户可能比外部账户更昂贵；所提出的解决方案将随着技术进步而不断发展。

加密用户体验很糟糕？是密钥管理烂透了！

在区块链领域，区块链资产的真正控制权并不在用户或钱包提供商手中，而在于私钥。这个密钥决定了以太坊上交易执行的成败。为了更好地理解这一点，我们以外部账户为例：

• 密钥生成：从 secp 256 k1 椭圆曲线中选择的一个随机数作为私钥。然后将该私钥乘以曲线上的预定义点以生成公钥。以太坊地址是从公钥哈希后的最后 20 个字节派生出来的。通常，我们会使用助记词，将私钥转为人类可读的词作为备份，从而最终生成私钥和公钥。
• 签署交易：使用私钥对一个包含了 nonce（序列号）、金额、gas 价格和接收地址等详细信息的交易进行签名。这个过程涉及到椭圆曲线数字签名算法 (ECDSA)，这种数字签名算法使用椭圆曲线密码学，并采用 secp 256 k1 曲线，生成由（r、s、v）值组成的签名，然后将签名和原始交易广播到网络上。
• 验证交易：一旦交易到达以太坊节点，它将在节点的内存池中进行验证。为了验证签名者，节点使用签名和散列交易获得发送者的公钥，并通过将提取的地址与发送者的地址进行匹配来确认交易的真实性。

正如上文所述，私钥是链上的一个重要实体。最初，以太坊账户，即外部账户，完全依赖于单个私钥，这带来了重大风险，因为丢失私钥意味着失去了对账户的访问权限。

许多人可能认为账户抽象（AA）是用户体验问题的终极解决方案，我想说并不尽然。账户抽象将以太坊上的 validity rule（有效性规则）变为可编程的规则，而智能合约账户让其实现。账户抽象很强大，可以实现并行发送多个交易（抽象 nonce）、gas 赞助，支持使用 ERC 20 支付 gas（抽象 gas），还有一个与本文主题更相关的功能是 - 账户抽象可以打破固定签名验证（抽象 ECDSA 签名）。与外部账户不同，智能合约账户可以分配任意签名者和签名机制，如多重签名 (multisigs) 或限定范围的密钥（会话密钥）。然而，尽管账户抽象的灵活性和可升级性有所提高，但交易签名仍需要密钥。

即使将私钥转换为 12 个单词的助记词，管理私钥仍是一大挑战，存在丢失或遭受钓鱼攻击的风险。用户必须在复杂的去中心化解决方案与中心化服务之间进行抉择，但两者都不是最理想的选择。

为什么加密体验很糟糕？其中很大一部分原因是因为密钥管理很糟糕。用户在密钥管理的时候，始终需要在体验、安全性和去中心化之间进行权衡。本文探讨了管理密钥的潜在最佳解决方案。

密钥管理层

永远不存在什么万全之策，密钥保管的最佳方式需要根据特定用户场景进行定制，并受诸多因素影响，如用户类型（机构还是个人）、资本金额、交易频率和交互类型等。

事先澄清一下，我不会用目前流行的「自我托管、半托管和完全托管」等字眼。在我看来，真正的自主托管意味着不依赖其他方、独立签署交易，哪怕有些解决方案在传统意义上都不算是托管（比如存储在去中心化节点的可信执行环境中），也不算非托管。仅基于托管类型来判断解决方案是好是坏就过于简单粗暴了，也没有考虑到这些方案的适用性差异。为了更加细致地评估密钥管理方法，我建议通过三个不同的维度对其进行分析。

责任

是否将密钥管理的责任划分给不同的责任方。

由于个人用户在管理密钥时通常面临种种挑战，分配密钥管理责任自然就成了一种风险缓解策略。这类方法包括使用多个密钥进行协作签名，多重签名（Multi-sig）系统便是一例，以及通过秘密共享方案（SSS）或多方计算（MPC）将私钥分为多个部分。

• 多重签名（Multi-sig）：需要多个完整的私钥来生成交易签名。这种方法需要不同签名者进行链上通信，交易费用更高，并影响隐私，因为签名者的数量在链上是可见的。
• 秘密共享方案 (SSS)：在单个位置生成私钥，然后将此密钥分为多个部分，分发给不同各方。各方必须重建完整的私钥以签署交易。然而，这种临时性重建可能会引入漏洞。
• MPC-TSS（阙值签名方案）：作为多方计算的一种实现，这种加密方法使多方能够在保持其输入共同私有的情况下进行计算。每一方都独立地创建一个密钥碎片，无需实际见面即可签署交易。因为是链下操作，这种方式所需的费用较低，且不存在秘密共享方案的单点故障风险。

存储

存储密钥或密钥碎片，受安全性、可访问性、成本和去中心化因素的影响。

• 中心化云服务，如 AWS、iCloud 等服务器。这种方式便于频繁交易，但更易受审查。
• IPFS 和 Filecoin 等去中心化存储。
• 本地计算机 / 移动设备：密钥存储在浏览器的安全存储中。
• 纸钱包：打印出私钥或二维码。
• 可信执行环境（TEE）：可信执行环境在主处理器内提供了一个安全区域，独立于主操作系统执行或存储敏感数据。
• Secure Enclave：现代设备上的 Secure Enclave 与主处理器隔离，提供额外的安全层，即使在应用程序处理器内核受到威胁时，也可保证敏感用户数据的安全。
• 硬件钱包：如 Ledger 和 Trezor 等物理设备，专门用于安全存储私钥。
• 硬件安全模块 (HSM)：硬件安全模块是专门用于安全密钥管理和加密操作的硬件设备，通常应用于企业环境，并提供高级别的安全功能。

访问

如何验证用户身份以访问存储的密钥

访问存储的密钥需要进行身份验证。这就需要去验证试图访问的个体是否确实得到了访问密钥的授权。回顾过去，可将访问方式分类如下：

• 你所知道的：密码、PIN 码、安全问题的答案或特定图形。
• 你所拥有的：包括智能卡、硬件代币（基于时间的一次性密码）或数字因素，如社交账户验证和发送到手机的短信代码。
• 你是谁：用户的独特身体特征，如指纹、面部识别（如 Apple 的 Face ID 或 Windows Hello）、语音识别或虹膜 / 视网膜扫描。

在这些基础上，双因素认证（2FA）和多因素认证（MFA）将至少两个因素结合起来，例如将短信与推送通知结合，加强用户账户的安全。

现有产品分析

MetaMask 允许用户使用密码访问存储在本地浏览器存储空间中的密钥。

Trust Wallet 允许用户使用密码或 faceID 访问存储在用户本地浏览器存储空间中的密钥，用户还可以选择使用云服务备份私钥。

Privy 允许用户使用电子邮件等多种社交登录方法，通过秘密共享方案将密钥分成三个部分：

• 设备分片：浏览器 -iFrame，移动端 -Secure Enclave。
• Auth 认证分片：由 Privy 存储，链接到 Privy ID。
• Recovery 恢复分片：用户密码或由 Privy 加密存储在硬件安全模块（HSM）中。

Particle 允许用户采用社交登录，使用 MPC-TSS，将密钥分为两个部分：

• 设备分片：浏览器 -iFrame
• 服务器密钥部分：Particle 的服务器

新解决方案

密钥层：WebAuthn、Secure Enclave 和 Passkey

上述现有解决方案在吸引用户关注 Web3 这一方面起到了关键作用。然而，挑战也随之而来：密码可能会被遗忘或成为网络钓鱼攻击的目标，2FA 虽然更安全，但由于涉及多个步骤，用起来还是很麻烦。此外，并不是所有人都愿意委托第三方进行密钥管理，当有些服务阻止用户访问密钥时，用户仍要依赖于系统的可用性和有效性。

这让我们思考是否有更有效的解决方案——一种能够提供近乎无信任、高安全性和无缝用户体验的解决方案。对这种方案的追寻引导我们找到最优的 Web2 方法。正如本文开头所述，有几个术语与该主题密切相关，WebAuthn 是身份验证标准，而 Secure Enclave 和 Passkey 则是与该标准相关的部署或组件。

WebAuthn

WebAuthn 规范了对基于 Web 的应用进行用户身份验证的接口。用户可使用外部验证器而非密码登录互联网账户。验证器可以是漫游认证器（如 Yubikey、Titan key）或平台验证器（如 Apple 设备上的内置钥匙串 (keychain)）等。

WebAuthn 背后的技术最初是由 FIDO（Fast IDentity Online）联盟所开发。2019 年 3 月，W3C 正式宣布将 WebAuthn 作为 Web 标准，随着其标准化的发展，各大浏览器如 Google Chrome、Mozilla Firefox、Microsoft Edge 和 Apple Safari 都采用了 WebAuthn，显著扩大了 WebAuthn 的应用范围和可用性。现已得到许多先进设备的支持。

WebAuthn 的优势：

• 安全性更高：不再依赖密码的依赖，减少网络钓鱼、暴力破解和重放攻击的风险。
• 提升用户体验：提供更简单、更快速的登录，通常只需一次点击或生物识别验证即可登录。
• 隐私保护：在身份验证过程中不会传输共享秘密内容，个别网站也不会接收到任何个人身份信息。
• 可扩展性和标准化：作为一种 Web 标准，WebAuthn 确保了不同浏览器和平台之间的一致性和互操作性。

基于设备的 WebAuthn，例如 Secure Enclave

现在，我们可以使用硬件处理器作为身份验证器，例如 Apple 设备的 Secure Enclave、Android 设备的 Trustzone 和 Google Pixel 的 Strongbox。

• 密钥生成：使用公钥加密，根据 WebAuthn 标准生成密钥对，通常采用的是 P-256 r 1 曲线。将公钥发送至服务端，而私钥永远不会离开 Secure Enclave。用户永远不会处理明文密钥，由此保障了私钥安全。
• 密钥存储：私钥安全地存储在设备的 Secure Enclave 内，这一经强化的子系统与主处理器隔离。它保护敏感数据，即使主系统受到损害，原始密钥资料也无法访问。破解 Secure Enclave 的门槛非常高，因此最敏感的数据类型（如 Apple Pay 和 FaceID 数据）都存储在这里。这里可以查看对 Secure Enclave 工作原理的深入解释。
• 身份验证：用户使用面部识别或指纹获取访问权限，Secure Enclave 使用私钥对服务端的挑战进行签名，而服务端则使用公钥进行验证。

基于设备的 WebAuthn 的优势：

• 媲美硬件的安全性：Secure Enclave 这样一个独立的基于硬件的密钥管理器提升了安全。
• 抵抗网络钓鱼攻击：不要在可能受到威胁的设备或网站上输入任何信息。
• 便捷的体验：提供更加用户友好的体验。用户不再需要记住不同网站的复杂密码。

基于设备的 WebAuthn 的缺点：

• 设备限制：如果设备丢失或损坏，则无法导出或检索私钥，无法进行跨设备操作。

基于云的 WebAuthn，Passkey

为解决跨设备功能的挑战，科技巨头推出了基于云的 WebAuthn 部署，Passkey 因为 Apple 而广为人知。

以 Apple 的 Passkey 为例：

• 密钥生成：用户的 macOS、iOS 或 iPadOS 设备作为验证器，在用户创建账户时生成公钥和私钥。然后将公钥发送至服务器，而私钥则存储在设备的 iCloud 钥匙串中。iCloud 钥匙串数据用硬件绑定的密钥对进行加密，并存储在硬件安全模块中。Apple 无法访问该密钥对。
• 跨设备同步：这个过程与访问 iCloud 相同。对 iCloud 账户进行认证，接收短信验证码，然后输入其中一台设备的密码。

基于云的 WebAuthn 的优势：

• 跨设备：Passkey 旨在方便用户访问，用户可在经常使用的所有设备上访问。但目前仅限于 Apple 设备。这种方式对于 Android 设备来说更具挑战性，因为 Android 的版本和硬件种类繁多。
• 防网络钓鱼攻击：同上。
• 便捷的体验：同上。

基于云的 Passkey 的缺点：

• 依赖云服务：与基于设备的 WebAuthn 相比，基于云的 Passkey 将安全层从 Secure Enclave 的硬件转移到 iCloud 钥匙串，有些人可能会认为它托管在云服务上。需要考虑的一些关键点包括：用户 iCloud 的 AppleID 账户是否被泄露；虽然 iCloud 钥匙串采用端到端加密来保护数据，但操作错误或漏洞都会带来风险。
• 平台限制：例如，在 Android 设备上使用基于 iCloud 的密码极具挑战性。此外，与传统方法不同，Apple 和 Google 不发送特定于设备的断言 (assertions)。这意味着目前无法验证生成密钥的设备类型，由此引发了对密钥及其相关元数据可靠性的质疑。

账户层：智能合约账户和外部账户

到目前为止，我们可以看到，在解决跨设备和跨平台兼容性的同时保持硬件的安全性是一大挑战。与之同样重要的是社交恢复选项，例如添加多个守护者 (guardian) 以增强安全性。在这种情况下，区块链可以为我们指明一条道路。

请注意：当我们尝试将 Web2 的 WebAuthn 部署到 Web3 时，一个明显的差异在于，Web2 只需要证明所有权，而 Web3 还需要同时授权交易。如果只拥有 Passkey，开发人员无法控制签名消息，签名消息通常是通用的，比如「sign in」。这可能导致潜在的前端操控问题，即用户「盲目」签署消息——这个问题看似微不足道，实则至关重要。

智能合约账户本身就是智能合约，作为链上实体，智能合约账户能够指定任意签名者。这种灵活性允许用户对各种设备和平台进行设置，比如将 Android 手机、Macbook 和 iPhone 设置为签名者。此外，模块化智能合约账户支持升级，可交换新的签名者，可将签名阈值从 2/3 更改为更复杂的配置。

想象一下，一个钱包可以根据情况灵活调整其安全需求：当用户在熟悉的本地 IP 地址上时，这个钱包支持单签名者身份验证，但对于来自未知 IP 地址或超过一定值的交易则需要多个签名者。有了模块化和可编程性，只有我们想象不到、没有实现不了的创新。许多智能合约账户服务提供商都在积极构建这一领域，包括 Safe、Zerodev、Biconomy、Etherspots、Rhinestone 等。还要感谢诸如 Stackup、Plimico、Alchemy 之类的基础设施，让这一切成为可能。

请查看我先前的研究，以获取有关智能合约账户更全面的背景信息。

智能合约账户可以通过多方计算服务实现社交恢复和跨设备 / 平台兼容性。尽管智能合约账户具有固定的签名者，但多方计算提供商可以将密钥分割成多个部分，以增强安全性和灵活性。这种方法不具备智能合约账户的可编程和可升级特性，例如时间锁恢复 (timelock recovery) 和轻松停用密钥功能。然而，MPC 不受特定区块链的限制，因此具有卓越的跨链能力，比智能合约账户更具成本效益。著名的多方计算提供商有 Particle Network、Privy、web3 Auth、OKX Wallet、Binance Wallet 等。

签名层：R1 支持

让我们退一步来理解：在以太坊上，私钥是从 k1 曲线中选择的随机数，并且签名过程也利用了这个曲线。

然而，根据 WebAuthn 标准生成的密钥对使用的是 r1 曲线。因此，在以太坊上验证 r1 签名的成本大约是 k1 签名的三倍。以下是针对这一问题的解决方案：

协议解决方案：

• 解决方案：EIP7212  ，预编译支持 secp 256 r1 曲线，由 Clave 团队提议。
• 评估：该提案创建了一个预编译合约，该合约通过给定的消息哈希、签名的 r 和 s，以及公钥的 x、y 坐标参数在「secp 256 r1」椭圆曲线中执行签名验证。因此，任何 EVM 链（主要是以太坊的 Rollups）都可以轻松地集成这个预编译合约。到目前为止，协议预编译可能是最节省 gas 的解决方案。
• 应用：zkSync

第三方服务：

• 解决方案：Turnkey
• 评估：Turnkey TEE 确保私钥仅可由用户通过其 Passkey 访问，Turnkey 永远无法访问私钥，然而这仍然需要该服务的有效性。
• 实现：Goldfinch

Solidity Verifier 解决方案：

• 解决方案：FCL 的 Solidity Verifier，FCL 带预计算 Solidity Verifier，Daimo 的 P 256 Verifier
• 实现：Clave，Obvious Wallet

零知识（ZK）验证器：

• 解决方案：Risc Zero 的 Bonsai，Axiom 的 halo 2-ecc
• 评估：这种方法利用零知识证明来验证以太坊虚拟机（EVM）之外的计算，降低链上计算成本。
• 实现：Bonfire Wallet (Risc Zero)，Know Nothing Labs (Axiom)

这些解决方案都可以在以太坊生态中实现更便宜和可行的 r1 签名验证，以下是 Dogan 的评估。

WebAuthn 新案例研究

* 请注意，截至 2023 年 12 月，这些解决方案大多处于早期阶段，可能随时发生变化或改进。这些示例仅供学习目的；请始终参考它们的官方网站获取准确信息。

Clave 钱包：（Secure Enclave WebAuthn）+（智能合约账户）

基本信息：

• 演示：https://getclave.io/
• 账户：智能合约账户
• 链：ZkSync

交易过程：

• 密钥创建：用户进行生物识别验证，如指纹或面部识别，在 Secure Enclave 内生成密钥对，永远不会泄露。
• 密钥签名：应用程序接收所需的交易消息，并将签名请求转发到 Secure Enclave，用户进行生物验证以批准签名，Secure Enclave 使用密钥对消息进行签名，然后广播到区块链节点。
• 附加功能：智能合约账户支持许多强大的功能。首先是 gas 赞助。使用 Paymaster，dApp 或广告商等都可以为用户支付 gas，使交易过程更加顺畅，同时还允许用户使用 ERC 20 代币支付 gas，而非只能用以太币或原生代币。此外，用户可使用会话密钥，在一段时间内进行无需签名的交易。

恢复机制：

• 恢复过程由 Clave 在 zkSync 上的智能合约进行，用户可以在 48 小时的锁定期内取消恢复，以防止未经授权的恶意活动。
• 云备份：用户选择云备份时，将创建一个外部账户，该外部账户的私钥存储在 iCloud 或 Google Drive 中，用户可以使用存储在云端的私钥从不同设备访问其账户，还可以随时删除或覆盖此备份部分。
• 社交恢复：用户可以指定其家人或朋友的 Clave 地址作为备份，如果 N 个守护者中有 M 个确认恢复且未取消，则在 48 小时锁定期后恢复执行。

Soul 钱包：（Passkey）+（4337 SCA）

基本信息：

• 演示：https://alpha.soulwallet.io/wallet
• 账户：ERC 4337 智能合约账户
• 链：以太坊、Optimism、Arbitrum，很快将全面支持以太坊虚拟机 Layer 2 

交易过程：

• 密钥创建：用户提供指纹或面部识别等生物识别验证，操作系统生成 Passkey，并使用云服务进行备份。用户可以跨设备和跨平台添加多个 Passkey。
• 添加守护者（可选）：用户可以指定不同的以太坊虚拟机外部账户地址作为守护者，并设置账户恢复阈值。
• 账户生成：利用反事实部署，用户进行第一笔交易之前都无需支付任何费用。

恢复机制：

• Passkey：使用任意定义的 Passkey 在任意设备上登录钱包。
• 守护者恢复：指定的守护者可以根据阈值轮换钱包，可稍后设置时间锁以防止恶意行为。

OKX 钱包：（MPC-TSS + Passkey）+（4337 智能合约外部账户）

基本信息：

• 演示：https://www.okx.com/help/what-is-an-aa-smart-contract-wallet
• 链： 30+ 条链
• 密钥：MPC-TSS， 2/3 
• 账户： 4337 智能合约账户

交易过程：

• 密钥创建：通过创建钱包，OKX 将单个私钥分为三个单独的部分。一个部分存储在 OKX 服务器上，一个部分存储在用户设备的本地存储中，还有一个部分由设备生成，经加密处理并可以备份到设备首选的云服务上，如 Google Cloud、iCloud 和华为云。
• 密钥签名：OKX 使用 MPC-TSS 技术，用户在签署交易时可以通过使用三个私钥部分中的两个获得完整的签名，在此过程中，私钥碎片彼此不会相互接触。

恢复机制：

• 2/3 机制：当用户注销、设备不可用或设备上的其中一个密钥被泄露时，用户可以使用新设备登录 OKX 钱包（获取服务器存储的密钥）并获取云服务存储的密钥部分，使用这两个部密钥恢复钱包，OKX 钱包将生成新的密钥部分。

Web3 Auth:（MPC-TSS +Passkey）+（外部账户 / 智能合约账户）

基本信息：

• 演示：https://w3a.link/passkeysDemo
• 链：所有 EVM 和 Solana
• 密钥：MPC-TSS，通常是 2/3 
• 账户：外部账户、 4337 智能合约账户或通用智能合约账户等任何账户

交易过程：

• 密钥创建：通过创建钱包，生成三个密钥部分。一个部分用于社交登录，用户可以输入他们的电子邮件，去中心化网络节点存储每个用户的密钥；一个部分是存储在用户设备的本地存储中的密钥；还有一个部分由本地计算机生成，并由用户首选的云服务进行备份。
• 密钥签名：Web3 Auth MPC-TSS 架构确保用户的密钥始终可用，即使使用阈值签名，密钥也永远不会重构或存储在单个位置。

恢复机制：

• 阈值恢复：当用户注销、设备不可用或设备上的某个密钥被泄露时，用户可以使用社交登录方法登录 WebAuthn 账户并获取云存储的密钥部分，使用这两个部分的密钥恢复钱包。

Lit Protocol (MPC-TSS + 去中心化节点 + Passkey) + ( 外部账户 / 智能合约账户 )

基本信息：

• 演示：https://lit-pkp-auth-demo.vercel.app/
• 链：大多数 EVM，Cosmos，Solana。
• 账户：MPC-TSS， 2/3 机制，可以同时适用于智能合约账户和外部账户。

交易过程：

• 密钥创建：当用户想要创建钱包时，首先选择身份验证方法（支持 Passkey、oAuth 社交登录），然后将请求发送到中继器以创建密钥对，并将身份验证逻辑存储到智能合约中。每个密钥对由 Lit 节点通过分布式密钥生成（DKG）过程共同生成。作为一个去中心化网络，TEE 内部运行 30 个 Lit 节点，每个节点都持有密钥的一部分，但私钥永远不会完整存在于 TEE 中。
• 密钥签名：收到请求后，Lit 节点根据指定的身份验证方法独立验证或拒绝请求，并使用 MPC-TSS 技术， 1. 收集超过阈值（30 个节点中有 20 个确认）时生成签名，并由客户端组合以满足请求。

恢复机制：

• 2/3 机制：使用存储在智能合约中的身份验证方法访问账户，Lit 节点验证请求，如果超过 2/3 的节点确认，请求将继续进行。

展望

在 Layer 2、Layer 3 和数据可用性 (DA) 解决方案的大力推动下，我们力求改善区块链的性能。同时，我们将零知识证明隐私与透明性相结合，追求真正的安全性。所有的努力都朝着同一个目标：加密技术做好准备应用于用户的日常生活中。

我们很容易困在一个理想的技术梦中，但我们必须问自己：我们追求的是什么样的体验？我们设想的是这样一个世界：在这个世界里，加密货币应该是直观易懂的，而不是令人生畏的技术术语；在这个世界里，用户可以毫不犹豫地跳进兔子洞，不费吹灰之力。

想象一下，有一个名叫 Rui 的用户：她发现了一个很棒的 dApp，可以轻松使用面部识别或指纹进行注册，并可以设置备份或守护者。她可以使用 dApp 轻松执行交易，可能只需支付少量 ERC 20 费用，甚至可能根本不需要任何费用。之后，她可以自定义钱包设置，例如激活自动交易的时间锁，将另一个设备添加为备份签名者，或者修改她的守护者列表。

创业者们正在努力将这一切付诸现实。结合 WebAuthn 和 Passkey，我们增强了私钥管理，使其既安全又方便。在这一基础之上，智能合约账户作为一个实体，打开了个性化安全性和功能性的领域。至于 gas？借助 Paymaster，提供商可以为 swap 交易创建一个「金库」，甚至允许广告商为用户支付费用，因此 gas 也不再是负担了。这一演变的核心，特别是对以太坊主网及其等效的 Layer 2 来说，就是 ERC 4337 。ERC 4337 引入了另一种内存池，将智能合约账户交易与外部账户区分开来，而无需对协议进行重大修改。另一方面，一些 Layer 2 网络甚至原生采用智能合约账户，并将其无缝地集成到系统中。

要使一切变得简单，需要付出巨大的努力。我们还面临着许多挑战，比如降低智能合约账户的部署、验证和执行费用；标准化接口，以增强账户的互操作性；跨链同步账户状态等。感谢所有构建者，每一天，我们都离成功更近一步。我们的公司 SevenX，以及其他加密创业公司，已经准备好，为伟大的公司赋能，帮助它们实现愿景。

致谢：

感谢我最亲爱的朋友们对本文的审阅：

David Sneider, Lit Protocol 联合创始人

Henri Stern, Privy 联合创始人

Zhen, Web3 Auth 联合创始人

Dogan 和 Rafi, Clave 创始成员

Ivo, Ambire 创始人

Itmar, Argent 创始人

Kurt Larsen 和 Konrad, Rhinestone 联合创始人

Pengyu Wang 和 Peter Pan, Particle Network 联合创始人

OKX 钱包团队

David Kim, Trust Wallet 工程主管