钱包是用户和以太坊世界之间的连接窗口。
原文：What I would love to see in a wallet (vitalik.eth)
作者：Vitalik
编译：imToken
本文编译自 Vitalik 博客，原文链接请查阅：https://vitalik.eth.limo/general/2024/12/03/wallets.html
特别感谢 Liraz Siri、Yoav Weiss 以及 imToken、Metamask 和 OKX 开发人员的反馈和审核。
以太坊基础设施堆栈的一个关键层是钱包，但这经常被专注于 Layer1 的研究人员和开发人员所低估。实质上，钱包是用户和以太坊世界之间的连接窗口，并且，当用户只能从以太坊和其相关应用程序所提供的去中心化、抗审查、安全、隐私等属性中受益时，其实钱包自身也具备了这些属性。
最近，我们看到以太坊钱包在改善用户体验、安全性和功能方面取得了很大进展。撰写这篇文章的目的是针对「理想的以太坊钱包应具备怎样的特性」提出我的看法。我的看法并不全面，会专注在阐释有关钱包安全和隐私的属性，这反映了我的密码朋克（Cypherpunk）倾向。
此外，虽然钱包在用户体验方面的特性肯定是不完整的，但我认为通过「愿望清单」的形式去优化用户体验不如依据反馈进行部署和迭代的实践操作有效，因此，我认为我的看法聚焦在探讨钱包的安全和隐私属性上是最有价值的。
「全文速览」
- Layer2 跨链交易的用户体验
- 钱包如何应对账户安全
- 钱包如何实现隐私保护
- 如何进行安全的链访问
- 对 DApp 安全的探讨
- 理想的 Keystore 钱包
- 与 AI 等新范式技术结合的更长远未来
跨 Layer2 交易的用户体验
现在有一个越来越详细的改善跨 Layer2 用户体验的路线图，该路线图有短期部分和长期部分。在这里，我将谈论短期部分：即使在今天理论上仍然可以实施的想法。
这份短期路线图的核心思想是：（i）内置 Layer2 跨链发送，以及（ii）链特定地址和支付请求。你的钱包应该能够为你提供一个地址（遵循本 ERC 草案的风格），如下图所示：
当某人（或某些应用程序）向你提供这种格式的地址时，你应该能够将其粘贴到钱包的「收件人」字段中，然后单击「发送」。钱包应该以任何可能的方式自动处理发送的数据：
- 如果你在目标链上已经有足够的所需类型的资产 ，请直接发送。
- 如果你在另一条链上有所需类型的资产（或多个其他链），使用 ERC-7683 等协议 （实际上是一个跨链 DEX）发送。
- 如果你在同一链或其他链上有不同类型的资产， 使用去中心化交易所将它们转换为正确链上正确类型的资产并发送。这应该需要用户的明确许可：用户将看到他们支付了多少费用、接收者收到了多少费用。
具有跨链地址支持的可能钱包接口的模型上面的内容适用于「你复制粘贴地址（或 ENS，例如 vitalik.eth @ optimism.eth）有人向你付款」的用例。
如果 DApp 请求押金（可参见 Polymarket 案例：https://x.com/VitalikButerin/status/1810633473750683974），那么理想的流程是扩展 Web3 API 并允许 DApp 发出特定于链的支付请求。然后，你的钱包将能够以任何需要的方式满足该请求。
同时，如果追求用户体验良好，还需要标准化 getAvailableBalance 请求，并且钱包需要认真考虑默认将用户资产存储在哪些链上，以最大程度地提高安全性和资产转移的便利性。
特定于链的支付请求也可以放入二维码中，移动钱包可以扫描二维码。在面对面（或在线）消费者支付场景中，接收者将发出 QR 码或 Web3 API 调用，表示「我想要 Z 链上 X 数量的的资产 Y ，带有参考 ID 或回调 W」，钱包将可以以任何方式自由满足该请求。
另一种选择是 claim link 协议，其中用户的钱包生成包含索赔授权的 QR 代码或 URL 从他们的链上合约中获取一定数量的资产，接收者的工作就是弄清楚如何将这些资产转移到他们自己的钱包中。
另一个相关主题是 Gas 费用的支付。如果你在 Layer2 上收到资产，但你在这个 Layer2 上尚未拥有 ETH，同时你需要在该 Layer2 上发送交易，钱包应该能够自动使用协议（例如 RIP-7755）在你拥有 ETH 的链上支付 Gas 费用。
如果钱包希望你将来能在这个 Layer2 上进行更多的交易，它也应该直接通过去中心化交易所（DEX）转移例如需要数百万 Gas 费用的 ETH，这样未来的交易可以直接在该 Layer2 上支付 Gas 费用（因为这样会更便宜）。
账户安全
我对账户安全挑战的概念化的一种方式是：一个好的钱包应该同时在两个方面发挥作用： （i）保护用户免受钱包开发人员的黑客攻击或恶意攻击，以及（ii）保护用户免受自己的错误的影响。
左边的「错误」是无意的。然而，当我看到它时，我意识到它非常适合上下文，所以我决定保留它。
十余年来，我对此的首选解决方案一直是社交恢复和多重签名钱包，具有分级访问控制。通常，用户的帐户有两层密钥：一个主密钥（Primary key）和 N 个监护人（Guardians)（例如 N = 5）。主密钥是能够进行低价值和非财务操作。大多数监护人需要执行 (i) 高价值操作，例如发送帐户中的全部价值，或 (ii) 更改主密钥或任何监护人。如果需要，可以允许主密钥通过时间锁执行高价值操作。
以上是基本设计，可以进行扩展。会话密钥和 ERC-7715 等权限机制可以帮助支持不同应用程序的便利性和安全性之间的不同平衡。更复杂的监护人架构，例如在不同阈值下具有多个时间锁定持续时间，可以帮助最大限度地提高成功恢复合法帐户的机会，同时最大限度地降低盗窃风险。
监护人是什么？
对于经验丰富的加密用户，如社区中的经验丰富的加密用户来说，一个可行的选择是你朋友和家人的密钥。如果你要求每个人为你提供一个新的地址，那么没有人需要知道他们是谁 —— 事实上，你的监护人甚至不需要知道彼此是谁。如果他们没有向你通风报信，他们串通一气的可能性很小。然而，对于大多数新用户来说，此选项不可用。
第二种选择是机构监护人：这种机构监护人是能够提供仅在收到你的请求的其他确认信息时（如确认码或针对高价值用户的视频通话）才签署交易的服务的实体机构。例如。我在 2013 年对 CryptoCorp 进行了介绍。然而，到目前为止，这些实体机构还不是很成功。
第三种选择是多个个人设备（例如电话、台式机、硬件钱包）。虽然这也是可以实践操作的，但对于没有经验的用户来说也很难设置和管理，同时还存在设备同时丢失或被盗的风险，尤其是当它们位于同一位置时。
最近，我们开始看到越来越多基于密钥（Passkey）设计的钱包。密钥只能备份在你的设备上，使其成为一种个人设备解决方案，也可以备份在云中，使其安全性依赖于复杂的混合密码安全、机构和可信硬件假设。实际上，密钥对于普通用户来说是一种宝贵的安全增益， 但仅靠它们还不足以保护用户的毕生积蓄。
幸运的是，有了 ZK-SNARK，我们还有第四种选择： ZK 包裹的中心化 ID 。这种类型包括 zk-email 、 Anon Aadhaar 、 Myna Wallet 等等。基本上，你可以采用多种形式（公司或政府）中心化 ID，并将其转换为以太坊地址，你只能通过生成证明拥有中心化 ID 的 ZK-SNARK 来发送交易。
有了这个补充，我们现在有了广泛的选择，并且 ZK 包装的中心化 ID 具有独特的「新手友好性」。
为了实现这一点，需要通过一个简化且集成的用户界面（UI）来实施：你应该能够直接指定「example@gmail.com」作为监护人，并且系统应在后台自动生成对应的 zk-email 以太坊地址。高级用户应能够将自己的电子邮件（以及可能用于隐私保护的 Salt Value）输入到一个开源的第三方应用程序中，并确认生成的地址是正确的。对于任何其他支持的监护人类型，也应该如此。
请注意，目前 zk-email 的一个实际挑战是它依赖于 DKIM 签名，而这些签名使用的密钥每隔几个月就会更换一次，并且这些密钥本身并未由其他权威机构签署。这意味着目前的 zk-email 需要在提供商之外附加一定程度的信任。如果 zk-email 使用可信硬件中的 TLSNotary 来验证更新后的密钥，这种信任需求可以减少，但这并非理想的解决方案。希望未来电子邮件提供商能够直接签署他们的 DKIM 密钥。目前，我建议将 zk-email 用于一个监护人，但不要让它占多数监护人份额：不要在一个依赖 zk-email 的设置中存储资金，因为如果 zk-email 出现问题，你可能会因此失去资金的访问权限。
新用户和应用程序内置钱包
新用户实际上不希望在第一次注册时输入大量监护人。因此，钱包应该为他们提供一个非常简单的选择。一种自然的途径是在其电子邮件地址上使用 zk-email、本地存储在用户设备上的密钥和提供商持有的备份密钥，进行 2-of-3 的选择。随着用户变得更有经验或积累更多资产，在某些时候应该提示他们添加更多监护人。
钱包集成到应用程序中是不可避免的，因为试图吸引非加密用户的应用程序不希望用户同时下载两个新应用程序（应用程序本身，加上以太坊钱包）带来混乱的用户体验。然而，许多应用程序钱包的用户应该能够将他们的所有钱包链接在一起，这样他们就只需担心一个「访问控制问题」。最简单的方法是采用分层方案，其中有一个快速的 “链接” 过程，允许用户将其主钱包设置为所有应用内钱包的监护人。Farcaster 客户端 Warpcast 已经支持这一点：
保护用户免受诈骗和其他外部威胁
除了帐户安全之外，当今的钱包还做了很多工作来识别虚假地址、网络钓鱼、诈骗和其他外部威胁，并尽力保护用户免受此类威胁。但是，许多对策仍然相当原始：例如，要求点击才能将 ETH 或其他资产发送到任何新地址，无论你发送的是 100 美元还是 100,000 美元。在这里，不存在单一的灵丹妙药 —— 这是针对不同类别威胁的一系列缓慢的持续修复和改进。然而，继续努力改进这里有很多价值。
隐私
现在是时候开始更加认真地对待以太坊的隐私了。ZK-SNARK 技术现在已经非常先进，不依赖后门来降低监管风险的隐私技术（例如隐私池）越来越成熟，而像 Waku 和 ERC-4337 mempools 这样的二级基础设施也慢慢变得更加稳定。
然而，到目前为止，在以太坊上进行私人资产转移需要用户明确下载并使用「隐私钱包」，例如 Railway（或用于隐形地址的 Umbra），这增加了不便并减少了愿意进行私人资产转移的用户数量，而这一切的解决办法是将私人资产转移需要直接集成到钱包中。
一个简单的实现方案如下：钱包可以将用户部分资产存储为隐私池中的「私人余额」。当用户进行资产转移时，系统会优先从隐私池中自动提取资金。如果用户需要接收资金，钱包可以自动生成一个隐秘地址。
此外，钱包还可以为用户参与的每个应用程序（例如一个 DeFi 协议）自动生成一个新的地址。存款将来自隐私池，而提款则直接进入隐私池。这种方式能够使用户在某一应用中的活动与他们在其他应用中的活动相互隔离，避免关联。
这项技术的一个优点是：它不仅是保护隐私的资产转移的自然路径，也为隐私保护身份提供了路径。
身份识别已经在链上实现：任何使用「身份认证」门槛的应用（例如 Gitcoin Grants）、任何基于 Token 的聊天功能、Ethereum Follow Protocol 等，都是链上的身份识别，我们希望这个生态系统也能实现隐私保护。
这意味着用户的链上活动不应该集中存储在一个地方：每项数据都应该单独存储，而用户的钱包应该是唯一能够「全局查看」所有认证信息的工具。能够支持每个用户拥有多个账户的原生生态系统，以及像 EAS 和 Zupass 这样的链下认证协议，都有助于实现这一目标。
这代表了以太坊在中期未来实现隐私保护的务实愿景。虽然目前就可以实施，但在 Layer1 和 Layer2 还可以引入一些功能，以使隐私保护更加高效和可靠。
一些隐私倡导者认为，唯一可以接受的方案是实现全面隐私：例如对整个 EVM 进行加密。我认为，尽管这可能是一个长期理想的目标，但它需要对编程模型进行更为根本性的重新设计，目前尚未成熟到可以在整个以太坊上部署的程度。
我们确实需要默认隐私来建立足够大的匿名数据集。不过，我们可以首先关注以下两个方面，这是相对而言更加务实、更加容易实现的初步措施，并且钱包从现在就可以着手：
- 实现账户之间资产操作的隐私保护。
- 为身份和与身份相关的用例（如认证）提供隐私保护。
以太坊钱包也需要成为数据钱包
任何有效的隐私解决方案，无论是针对支付、身份还是其他用例，都不可避免地需要用户存储链下数据。这在 Tornado Cash 中表现的尤为明显 —— 它要求用户保存下每笔独立的、代表存入了 ETH（存入范围：0.1 ETH ~ 100 ETH）的「备注凭证」。
一些更现代的隐私协议有时会将数据加密存储在链上，并使用单一私钥进行解密。这也是有风险的，因为如果密钥泄露，或者量子计算机变得可行，数据就会全部公开。EAS 和 Zupass 这样的链下证明协议对链下数据存储的需求更为明显。
钱包不仅需要成为一个能够存储链上访问权限的软件，还需要成为一个能够存储私人数据的工具。非加密的世界里也越来越意识到这个需求的重要性。例如，可以参考 Tim Berners Lee 最近在研究的有关个人数据储存方面的工作。
这些亟待解决的问题其实都围绕在要设计有稳健的、能保障访问权限控制的方案和稳健的、保障数据可访问，同时防止数据防泄露的方案。
或许这些解决方案可以叠加在一起：如果你有 N 个监护人，可以在这 N 个监护人之间使用 M-of-N 秘密共享方案来存储你的数据。数据的安全性本质上更难保障，因为你无法撤销某人对数据的份额，但我们应努力设计出尽可能安全的去中心化托管解决方案。
安全的链访问
如今，钱包服务商信任他们的区块链远程调用接口服务商（RPC Provider) 会告知有关链的任何信息。但这种情况存在漏洞，漏洞包括以下两个方面：
- RPC 服务商可能会尝试通过提供虚假信息来窃取金钱，如虚假的市场价格。
- RPC 服务商可能提取有关用户在与哪些应用程序或账户进行交互的私人信息。
理想情况下，我们希望堵住这两个漏洞。为了解决第一个问题，我们需要 Layer1 和 Layer2 的标准化轻客户端，它们可以直接验证区块链共识。
Helios 在 Layer1 上这样实践了，并在支持某些特定的 Layer2 项目上也开展了一些初步工作。
而为了正确覆盖所有 Layer2 的需求，我们需要一个标准，例如通过配置合约来表示一个 Layer2（这也可用于表示某个链的特定地址），该合约可以声明一个函数（类似于 ERC-3668 的方式），用于获取最近的状态根（State root），并根据这些状态根验证状态（States）和记录（Recipits）的证明。
通过这种方式，我们可以实现一个通用的轻客户端，使钱包能够安全地验证 Layer1 和 Layer2 上的任何状态或事件。
对于隐私保护，目前唯一现实的做法是运行自己的完整节点。然而，随着 Layer2 的出现，运行所有内容的完整节点变得越来越困难。在这种情况下，与轻客户端对应的解决方案是私密信息检索（Private Information Retrieval, 简称 PIR）。
私密信息检索的工作原理是由服务器持有所有数据的副本，而客户端向服务器发送加密的请求。服务器对所有数据进行计算，并返回客户端所需的数据，这些数据会被加密成客户端的密钥，而服务器不会得知客户端访问了哪部分数据。
为了保持服务器的可信任性，各个独立的客户端可以将它们自身作为 Merkle 分支，如此一来，客户端可以使用轻客户端来验证数据完整性。
私密信息检索技术（PIR）的算量很大、计算成本非常高。针对这一问题，有以下几种可能的解决途径：
- 暴力方法：算法改进或专用硬件可能能够使私密信息检索技术的速度足够快以投入实际使用。这些技术可能依赖预处理，例如服务器为每个客户端存储加密和打乱的数据，客户端查询这些预处理后的数据。在以太坊的场景下，这个解决方案的主要挑战在于将这些技术适配于快速变化的数据集（如状态数据）。此外，虽然这种解决方案可以降低实时计算成本，但可能会显著提高总计算和存储成本。
- 弱化隐私要求：例如，每次查找只能有 100 万个混合项数据（Mixins），因此服务器虽然可以知道客户端可以访问的 100 万个数据中的某一个，但无法精准定位到具体的数据值。
- 多服务器私密信息检索：使用多个服务器，并在这些服务器之间采用「1-of-N 诚实性假设」，可以显著提升私密信息检索算法的速度。
- 使用匿名性代替保密性：通过混合网络（mixnet）发送请求，从而隐藏请求发送者的身份，通过这种解决方法替代隐藏请求的内容。然而，这种解决方案不可避免地会增加延迟，从而降低用户体验。
在以太坊环境下，找到能够在隐私性和实用性之间取得最佳平衡的技术组合仍然是一个未解决的研究问题。我欢迎密码学领域的研究人员尝试解决这一难题。
理想的 Keystore 钱包
除了资产转移和状态访问之外，在 Layer2 跨链环境中，还有一个需要顺畅运作的重要流程便是更改账户的验证配置：无论是更改其密钥（例如恢复密钥），还是更深层次地更改账户的整个逻辑。在这个问题上，有三个不同难度等级的解决方案：
- 更新回放：当用户更改其配置时，授权此更改的消息会在钱包检测到用户拥有资产的每个链上进行回放。潜在地，消息格式和验证规则可以设计为与链无关的信息，从而使得消息能够在尽可能多的链上自动回放。
- Layer1 上的 Keystore：配置信息位于 Layer1 上，Layer2 上的钱包使用 L1SLOAD 或 REMOTESTATICCALL 读取。这样一来，只需要在 Layer1 上更新配置，配置就会自动生效。
- Layer2 上的 Keystore：配置信息存在于 Layer2 上，Layer2 上的钱包使用 ZK-SNARK 读取。这与 上述第 2 个解决方案的实现原理相同，只是密钥存储的更新成本可能相对更便宜，但读取需要花费的成本较高。
在上述解决方案中，第 3 个解决方案特别强大，因为它与隐私保护非常契合。在正常的「隐私解决方案」中，用户有一个秘密 s，一个「leaf value」中的 L 被发布到链上，用户证明 L = hash(s, 1) 和 N = hash(s, 2)，其中 s 是一个从未透露的秘密，由用户控制。
当 N 被发布，确保未来使用相同「leaf」的支出失败，但从未透露 L。这依赖于用户保护好了 s。
而一个更适合恢复的隐私解决方案则会说：s 是链上的一个位置（例如地址和存储槽），用户必须证明一个状态查询：L = hash(sload(s), 1)。
DApp 安全 用户安全中最薄弱的环节通常是 DApp。
大多数时候，用户通过访问网站与应用程序互动，网站会实时从服务器下载用户界面代码，并在浏览器中执行。如果服务器被黑客攻击，或者 DNS 被篡改，用户将看到一个假的界面副本，这可能会诱使用户执行任意操作。像交易模拟这样的钱包功能对于减轻这些风险非常有帮助，但它们远远不完美。
理想情况下，我们应该将生态系统迁移到链上的内容版本控制：用户将通过其 ENS 名称访问 DApp，该名称包含界面的 IPFS 哈希值。更新界面需要通过多签或 DAO 发起的链上交易。钱包会向用户显示他们是否在与更安全的链上界面互动，还是与不太安全的 Web2 界面互动。钱包还可以显示用户是否在与安全性较高的链（例如阶段 1+、经过多次安全审计的链）互动。
对于注重隐私的用户，钱包还可以添加一个偏执模式（Paranoid Mode），要求用户点击接受 HTTP 请求，而不仅仅是 Web3 操作。
偏执模式可能的界面模型一种超越 HTML + Javascript 的、更先进的方法是使用专有语言编写 DApp 的业务逻辑（这种语言不一定是一个复杂的全新语言或者框架，可以是 在 Solidity 或 Vyper 之上构建一个相对简单、轻量的附加层）。浏览器可以自动生成任何所需功能的用户交互界面。OKContract 已经在实践这一方法。
另一个方向是加密经济信息防御：DApp 开发人员、安全公司、链部署者和其他人可以设立一笔保证金，如果 DApp 被黑客攻击或以高度误导性的方式伤害用户，则该保证金将支付给受影响的用户，赔偿的具体标准由某个链上仲裁 DAO 确定。钱包可以向用户显示一个基于保证金大小的评分。
更长远的未来 以上内容是有关传统界面的讨论，这些界面涉及 「点击 」 「指向 」和在文本框中输入内容。然而，我们也正处在范式发生更深刻变化的边缘：
- 人工智能：使我们从 「点击和输入」范式转向 「说出你想做什么，机器人帮你搞定」的范式。
- 脑机接口：既有眼动追踪等 「温和」的方法，也有更直接地、甚至侵入性的技术。
可参考今年第一位 Neuralink 患者事件，详情查阅：https://www.wired.com/story/neuralink-first-patient-interview-noland-arbaugh-elon-musk/ - 客户端主动防御：可参考事件如 Brave 浏览器主动保护用户免受广告、跟踪器和许多其他不良对象的侵害。许多浏览器、插件和加密钱包都有整个团队积极致力于保护用户免受各种安全和隐私威胁。这些 「积极的守护者」在未来十年只会变得更加强大。
了解 Brave 浏览器主动防御，详情查阅：https://brave.com/shields/
这三种趋势的结合将促使我们对界面的工作方式进行更深刻的重新思考。通过自然语言输入、眼动追踪，或者最终更直接的脑机接口，加上对你的使用历史的了解（可能包括文本消息，只要所有数据都在本地处理），一个 「钱包 」可以直观地理解你想做什么。然后，人工智能技术可以将这种直觉转化为一个具体的 「行动计划 」：一系列链上和链下的交互，以实现你想要的目标。
如此这般，将大大减少完全依赖第三方用户界面的需求。如果用户确实与第三方应用（或其他用户）互动，人工智能技术应该代表用户采取对抗性思维，识别任何威胁并提出避免这些威胁的行动计划。理想情况下，会有一个由不同团体、带有不同偏见和激励结构的人工智能开发者构成的开放生态系统。
这些更为激进的想法依赖于目前非常不成熟的技术，因此我不会将我的资产放入依赖这些技术的钱包中。然而，这样的事情显然是未来的趋势，因此值得开始更加积极地朝着这个方向探索。
免责声明：作为区块链信息平台，本站所发布文章仅代表作者及嘉宾个人观点，与 Web3Caff 立场无关。文章内的信息仅供参考，均不构成任何投资建议及要约，并请您遵守所在国家或地区的相关法律法规。
