Vitalik：我心中理想的钱包应该长这样

撰文：Vitalik Buterin

编译：Yangz，Techub News

钱包是以太坊基础架构堆栈中的一个关键层，但它往往不被核心 L1 研究者和开发人员所重视。钱包是用户与以太坊世界之间的窗口，用户只有在钱包本身也具有去中心化、抗审查、安全、隐私或以太坊及其应用提供的其他特性的情况下，才能从中获益。

近些年，我们看到了以太坊生态钱包在改善用户体验、安全性和功能方面取得了很大进展。本文的目的是就理想的以太坊钱包应具备的一些属性发表我个人的看法。这份清单不会是完备的，但反映了我的加密朋克倾向。对于钱包，我更看重安全性和隐私性，因为在用户体验方面几乎不会有完美的钱包存在。我认为，愿望清单对于优化用户体验的效果不如简单地根据反馈进行部署和迭代，在我看来，关注安全和隐私属性是最有价值的。

跨 L2 交易的用户体验

目前改善跨 L2 用户体验的路线已越来越详尽，其中有短期部分，也有长期部分。在此，我想谈谈短期部分，也就是即使在今天，理论上也可以实现的想法。

这部分的核心理念是内置跨 L2 交易以及特定链地址和支付请求。钱包应该提供这样一种地址：

当某人（或某个应用）向你提供这种格式的地址时，你应该可以将其粘贴到钱包的「to」字段中，然后点击「send」，钱包就会自动处理：

如果目标链上已有足够的所需类型的代币，则直接发送；
如果你在另一条链（或多条链）上有所需类型的代币，则可以使用类似 ERC-7683 的协议（实际上是跨链 DEX）发送代币；
如果你在同一条链或其他链上拥有不同类型的代币，则可使用 DEX 将其转换为正确链上的正确类型代币并发送。当然，这也需要用户的明确许可，也就是说，用户将看到自己支付了多少钱，而接收者又收到了多少钱。

以上是「复制粘贴地址（或 ENS，例如 vitalik.eth@optimism.eth）让别人向您付款」的用例。如果是向 DApp 进行存款（请参阅 Polymarket 示例），那么理想的流程是扩展 Web3 API，允许 DApp 提出特定链的付款请求。这样，用户钱包就能以任何方式满足该请求。要使用户体验良好，还需要对 getAvailableBalance 请求进行标准化，而且钱包需要考虑将用户的资产默认存储在哪条链上，以最大限度地提高安全性和转账的便捷性。

针对特定链的支付请求也可以置于二维码中，方便手机钱包直接扫描。在当面（或在线）消费支付场景中，收款人可以通过二维码或 Web3 API 调用「我想要 Z 链上 X 单位的 Y 代币，并附带参考 ID 或回调 W」，而钱包则可以自由地以任何方式满足该请求。另一种方案是申领链接协议，即用户钱包可以生成一个二维码或 URL，其中包含从其链上合约中申领一定数量资金的授权，而收款人的工作就是想办法把这些资金转到自己的钱包中。

另一个相关的话题是 gas 支付。如果你在一个尚未拥有 ETH 的 L2 上收到资产，并且需要在该 L2 上发送一笔交易，那么钱包应该能够自动使用一个协议（例如 RIP-7755）在你拥有 ETH 的链上支付 gas。如果钱包预计你将来会在该 L2 上进行更多交易，那么它也应该使用 DEX 发送价值几百万 gas 的 ETH，以便未来的交易可以直接在使用 gas（这样也更便宜）。

账户安全

我对账户安全挑战的理解是，一个好的钱包应该既能保护用户免受钱包开发者的黑客攻击或恶意攻击，也能保护用户免受自身错误的伤害。

纵轴上的错别字「mistakles」是无心之失。我觉得这一错误很符合上下文，所以并没有进行修改。

十多年来，我首选的解决方案一直是社交恢复和多签钱包，并采用分级访问控制。单个用户账户设置两层密钥，包括一个主密钥和 N 个签名者（例如 N = 5）。主密钥可以进行低价值和非财务操作。但要进行高价值操作，如发送账户中的全部资产，或更改主密钥或任何签名者，则需要大多数签名者的参与。如果需要，可以允许主密钥进行带有时间锁的高价值操作。

以上只是基础的设计，我们还可以对其进行扩充。例如，会话密钥和权限机制（如 ERC-7715）可以帮助支持不同应用在便利性和安全性之间取得不同的平衡。更复杂的签名者架构，如在不同阈值下设置多个时间锁持续时间，有助于最大限度地提高成功找回合法账户的几率，同时最大限度地降低被盗风险。

多签钱包的签名者应该选谁？

对于经验丰富的加密货币用户来说，一个可行的选择是你的朋友和家人。事实上，你的多签钱包签名者甚至不需要知道彼此是谁。在你不知情的情况下，他们串通一气的可能性微乎其微。然而，对于大多数新用户来说，这种选择是不可行的。

第二种选择是机构，即那些专门提供服务的公司。这类签名者只有在获得其他确认信息（如确认码，或高净值用户的视频通话）后才会签署交易。很长时间以来，人们一直在尝试创建这样的公司，例如，我曾在 2013 年介绍过 CryptoCorp。不过，到目前为止，这类公司还没有很成功的代表。

第三种选择是使用多个个人设备（如手机、台式机、硬件钱包）。这种方法可以奏效，但对于缺乏经验的用户来说，也很难设置和管理。此外，还存在设备同时丢失或被盗的风险，尤其是当它们处于同一地点时。

最近，我们开始看到更多基于 passkey 的钱包出现。Passkey 可以只在设备上备份，使其成为一种个人到设备的解决方案，也可以在云端备份，使其安全性依赖于密码安全、机构和可信硬件假设的复杂混合体。实际上，passkey 对普通用户来说是一种宝贵的安全增益，但仅靠它还不足以保护用户的毕生积蓄。

幸运的是，有了 ZK-SNARK，我们有了第四种选择，即经 ZK 处理的中心化 ID。这一类型包括 zk-email、Anon Aadhaar、Myna Wallet 等。基本上，你可以使用多种形式的（企业或政府）中心化 ID，并将其转化为以太坊地址，只有生成 ZK-SNARK 证明拥有该 ID，你才能从该地址发送交易。

有了这个新功能，我们就有了多种选择，而且经 ZK 处理的中心化 ID 对新手非常友好。

要实现这一点，我们需要使用精简的集成用户界面。用户只需指定「example@gmail.com」作为签名者，钱包就会在自动生成相应的 zk-email 以太坊地址。此外，高级用户应能在开源第三方应用中输入自己的电子邮件（以及可能会保存在电子邮件中的隐私盐值），并确认生成的地址正确无误。任何其他受支持的签名者类型也应如此。

需要注意的是，zk-email 目前面临的一个实际挑战是，它依赖于 DKIM 签名，而 DKIM 签名使用的密钥每几个月轮换一次，而且这些密钥本身没有任何其他机构的签名。这就意味着除了提供商本身之外还有一定程度的信任要求；如果 zk-email 在受信任的硬件中使用 TLSNotary 来验证更新的密钥，则可以降低信任要求，但这并不理想。希望电子邮件提供商能开始直接签署 DKIM 密钥。此外，我建议只在一个签名者身上使用 zk-email，而不是大多数签名者。这样，即使 zk-email 崩溃，也不会失去资金访问权。

新用户和应用内钱包

现实中，新用户不会希望在首次注册时就输入大量多签钱包签名者的信息。因此，钱包们应该提供一个非常简单的选择。一种自然的方法是 3 个签名中有 2 个使用 zk-email，即用户设备上本地存储的密钥（可以是 passkey）和提供商持有的备份密钥。而随着用户经验的增加或资产的累积，在某些情况下，他们会被提示添加更多的签名者。

将钱包集成到应用中是不可避免的，因为试图吸引非加密货币用户的应用不会希望让用户同时下载两个新的应用（应用本身和以太坊钱包），从而造成不好的用户体验。使用多个钱包的用户也应该能够将所有钱包连接在一起，这样他们就只需要担心「访问控制问题」。最简单的方法是采用分层方案，通过快速的「链接」过程，用户可将自己的主钱包设置为所有应用内钱包的签名者。目前，Farcaster 客户端 Warpcast 已支持这种方式。

默认情况下， Warpcast 账户的恢复由 Warpcast 团队控制。但用户可以「接管」 Farcaster 账户，并将其改成自己的地址。

保护用户免受欺诈和其他外部威胁

除了账户安全之外，如今的钱包在识别虚假地址、网络钓鱼、诈骗和其他外部威胁方面也做了很多工作，并努力保护用户免受此类威胁。然而，许多反制措施仍然相当原始。例如，向任何新地址发送 ETH 或其他代币都只需点击就行，无论发送的是 100 美元还是 10 万美元。在这方面，没有单一的解决方案，而是要针对不同类别的威胁进行一系列缓慢的持续修复和改进。但是，继续努力改进是有很大价值的。

隐私

ZK-SNARK 技术已非常先进，而隐私池（Privacy Pools）等不依赖后门就能降低监管风险的隐私技术也越来越成熟，Waku 和 ERC-4337 等二级基础设施也慢慢变得更加稳定。然而，到目前为止，在以太坊上进行私密性的转账仍旧需要用户明确下载并使用「隐私钱包」，如 Railway（或用于隐身地址的 Umbra）。这给用户带来了极大的不便，也减少了此类用户的数量。对于这一问题，解决办法是将这类转账直接集成到钱包中。

一个简单的实现方法是，钱包可以将用户的部分资产作为「私人余额」存储在隐私池中。当用户进行转账时，会自动先从隐私池中提取。如果用户需要接收资金，钱包会自动生成一个隐身地址。此外，钱包还能为用户参与的每个应用（如 DeFi 协议）自动生成一个新地址。存款来自隐私池，取款直接进入隐私池。这样，用户在任何一个应用中的活动都与他们在其他应用中的活动无关。

这种技术的一个优势是，它不仅实现了资产转移的隐私性，也实现了身份识别的隐私性。目前，身份识别已在链上实现，任何使用 proof-of-personhood 的应用（如 Gitcoin Grants）、任何需要特定代币才能进行聊天、以及 Ethereum Follow 协议等都是链上身份识别。我们希望这个生态也能具有隐私性，也就是说，用户在链上的活动不应该被收集在一个地方，每个项目都应该单独存储，用户的钱包也应该是唯一具有「全局视图」的东西，可以同时看到你的所有证明。与 EAS 和 Zupass 等链外认证协议一样，每个用户拥有多个账户的原生生态有助于实现这一目标。

这代表了以太坊隐私在中期未来的务实愿景。尽管它可以在今天实现，但在 L1 和 L2 阶段引入一些功能，将使保护隐私的交易更高效、更可靠。一些隐私保护倡导者认为，唯一可以接受的是一切都完全隐私化，对整个 EVM 进行加密。但我认为，这可能是长期的理想结果，需要对编程模型进行更根本的重新思考，而且它目前还没有成熟到可以在以太坊上部署的程度。我们确实需要「默认隐私」（privacy-by-default）来获得足够大的匿名性。然而，专注于账户之间的转账，以及身份和与身份相关的用例）的私密性是务实的第一步，它更容易实现，可为钱包现阶段着手建设。

以太坊钱包也需要成为数据钱包

任何有效的隐私解决方案，无论是用于支付、身份识别还是其他用例，都会导致用户需要存储链下数据。这一点在 Tornado Cash 中就很明显，它要求用户保存代表 0.1-100 ETH 存款的每张「note」。而更现代的隐私协议有时会保存链上加密的数据，并使用单个私钥进行解密。然而，这是有风险的，因为如果密钥泄露，或者量子计算机成为可能，数据就会全部公开。届时，像 EAS 和 Zupass 这样的链下认证对链下数据存储的需求就会更为明显。

钱包不仅需要成为存储链上访问权限的软件，还需要成为存储私密数据的软件。这一点在非加密货币世界中也得到了越来越多的认可，具体可参阅 Tim Berners-Lee 最近在个人数据存储方面所做的研究。我们需要解决的所有问题，不仅要有力地保证访问权限的控制，还要有力地保证数据的可访问性和不泄漏。也许这两种解决方案可以叠加在一起，假设你设置了 N 个多签签名者，那么可以在这 N 个签名者之间使用 M-of-N 秘密共享来存储数据。从本质上讲，数据是更难确保安全的，因为你无法撤销别人的数据份额，但我们应该尽可能地提出安全的去中心化托管解决方案。

安全的区块链访问

许多钱包相信 RPC 提供商会告诉它们有关链的任何信息。这在两个方面存在漏洞。首先，RPC 提供商可能试图通过提供虚假信息（如市场价格）来窃取资金；其次，RPC 提供商可以提取用户与哪些应用和其他账户交互的私人信息。

理想情况下，我们需要要防止这两个漏洞的出现。要防止第一个漏洞，我们需要标准化的 L1 和 L2 轻客户端，直接验证区块链共识。Helios 已为 L1 实现了这一功能，并且已经开展了一些初步工作来支持一些特定的 L2。为了适当地覆盖所有 L2，我们需要一个标准，通过该标准，代表 L2 的配置合约（也用于特定链地址）可以发布一个函数（也许采用类似于 ERC-3668 的方式），其中包含获取最近状态根的逻辑，并根据这些状态根验证状态证明和收据。这样，我们就可以拥有一个通用的轻客户端，允许钱包安全地验证 L1 和 L2 上的任何状态或事件。

至于第二个漏洞，目前唯一可行的方法就是运行自己的全节点。然而，随着 L2 的普及，运行一个包含所有内容的完整节点变得越来越困难。针对这一问题，与轻客户端这一解决方案相当的是私人信息检索 (PIR)。PIR 涉及一个持有所有数据副本的服务器，以及一个向服务器发送加密请求的客户端。服务器对所有数据执行计算，返回客户端所需的数据（使用客户端的密钥加密），而不会向服务器透露客户端访问了哪些数据。

为了让服务器保持诚实，单个数据库项目本身需要是默克尔树分支，因此客户端可以使用自己的轻客户端对其进行验证。

PIR 的计算成本很高，但有几种方法可以解决这个问题：

蛮力：算法或专用硬件的改进有可能使 PIR 的运行速度足够快。这些技术可能依赖于预处理，即服务器为每个客户端存储经过加密和洗牌的数据，客户端可以查询这些数据。在以太坊环境中，主要的挑战在于如何使这些技术适应快速变化（如状态变化）的数据集。这将降低实时计算成本，但很可能会提高总计算和存储成本。
削弱隐私要求：例如，每次查询只能有 100 万个「mixins」，因此服务器会知道客户端可能访问的 100 万个可能值，但不会知道更细的粒度。
多服务器 PIR：如果使用多个服务器，并假设这些服务器之间的诚实度为 1-of-N，那么 PIR 算法的速度通常会快很多。
匿名性而非保密性：可以通过混合网络发送请求，隐藏请求的发送者，而不是隐藏请求的内容。然而，这样做会不可避免地增加延迟，使用户体验恶化。

在以太坊环境下，找出既能最大限度保护隐私又能保持实用性的技术组合是一个开放性的研究课题，欢迎密码学家们踊跃尝试。

理想的密钥存储钱包

除了传输和状态访问外，在跨 L2 环境下需要顺利运行的另一个重要工作流程是更改账户的验证配置（无论是更改密钥，还是对账户的整个逻辑进行更深层次的更改）。下面是三层解决方案，难度依次递增：

重放更新：当用户更改配置时，授权更改的消息会在钱包检测到用户拥有资产的每条链上重放。信息格式和验证规则可能与链无关，因此可以在尽可能多的链上自动重放。
L1 上的密钥存储：配置信息保存在 L1 上，L2 上的钱包通过 L1SLOAD 或 REMOTESTATICCALL 读取配置信息。这样，只需在 L1 上更新配置，配置就会自动生效。
L2 上的密钥存储：配置信息保存在 L2 上，L2 上的钱包通过 ZK-SNARK 读取配置信息。这与第（2）种情况相同，只是密钥存储更新的成本更低，而读取的成本则更高。

第三种解决方案特别强大，因为它能很好地与隐私堆叠。在普通的「隐私解决方案」中，假设用户有一个秘密 s，在链上发布了一个「leaf value」L ，用户证明 L = hash(s,1)以及 N = hash(s,2) 是其控制的某个（从未公开的）秘密。N 会被公布，以确保未来对同一 Leaf 的花费不会失败，且不会泄露 L。而在对账户恢复友好的隐私解决方案中，s 是链上的一个位置（如地址和存储 slot），用户必须证明状态查询，即 L = hash(sload(s), 1) 。

DApp 安全

用户安全中最薄弱的环节往往是 DApp。大多数情况下，用户通过访问网站与应用进行交互，网站会从服务器实时下载用户界面代码，然后在浏览器中执行。如果服务器被黑客攻击，或者 DNS 被黑客攻击，用户就会得到一个假的界面副本，从而诱使用户做一些任意事情。交易模拟等钱包功能对降低风险很有帮助，但还远远不够。

理想情况下，我们需要将生态转移到链上内容版本，用户将通过其 ENS 名称访问 DApp，该名称将包含接口的 IPFS 哈希值。要更新接口，就需要来自多 ID 或 DAO 的链上交易。钱包会向用户显示，他们是在与安全性更高的链上接口交互，还是在与安全性较低的 Web2 接口交互。钱包还可以向用户显示他们是否正在与安全的区块链（例如，stage 1+，多重安全审计）进行交互。

对于注重隐私的用户，钱包还可以更强硬一些，要求用户点击接受 HTTP 请求，而不仅仅是 Web3 操作。

一种更先进的方法是超越 HTML + Javascript，用一种专用语言编写 DApp 的业务逻辑，比如在 Solidity 或 Vyper 上覆盖一种相对轻型的语言。这样，浏览器就可以自动为任何需要的功能生成用户界面。OKContract 已经这么做了。另一个方向是加密经济信息防御，即 DApp 开发者、安全公司、链上部署者和其他人可以设立一个保证金，如果 DApp 被黑客攻击或以其他通过高度误导的方式损害了用户，该保证金将在链上裁决 DAO做出决定后，支付给受影响的用户。钱包可以向用户显示基于保证金大小的评分。

更长远的未来

以上所述都是在传统的背景下进行的，目前的我们也正处于模式发生深刻变化的边缘：

人工智能（AI）或将使我们从「click and type」的模式转变为「say and bot figures it out 」的模式。
脑机接口：既包括眼动追踪等相对「温和」的方法，也包括更直接、甚至侵入性的技术（如首位 Neuralink 患者）
客户端参与主动防御：Brave 浏览器主动保护用户免受广告、跟踪器和许多其他不良对象的侵害。许多浏览器、插件和加密货币钱包都有整个团队在积极保护用户免受各种安全和隐私威胁。未来十年，这类「主动守护者」将变得更加强大。

这三种趋势加在一起，将促使人们对钱包的工作方式进行更深入的反思。通过自然语言输入、眼球追踪或最终更直接的生物识别（BCI），再加上对用户历史记录的了解，「钱包」就能凭直觉清楚地知道用户想做什么。然后，AI 可以将这种直觉转化为具体的「行动计划」，比如一系列链上和链下的交互，从而实现用户意图。这可以大大减少对第三方用户界面的需求。如果用户确实与第三方应用（或其他用户）进行了交互，AI 也应该代表用户进行对抗性思考，识别任何威胁并提出避免威胁的行动计划。理想情况下，这些 AI 将形成一个开放的生态，由具有不同偏见和激励结构的不同团体生成。

当然，这些更为激进的想法依赖于目前还极不成熟的技术，因此我不会把我的资产放在依赖于这些技术的钱包里。不过，这类技术似乎是未来的趋势，因此值得我们开始朝这个方向进行更积极的探索。