我希望在钱包中看到的功能
作者：维塔利克·布特林 2024年12月03日 原文链接
特别感谢 Liraz Siri、Yoav Weiss，以及 ImToken、Metamask 和 OKX 的开发者们提供的反馈和评审。
以太坊基础设施栈中有一个关键层级——钱包，它常常被核心 L1 研究人员和开发者低估。钱包是用户与以太坊世界之间的窗口，用户只有在钱包本身具备相应特性的情况下，才能真正受益于以太坊及其应用所提供的去中心化、抗审查、安全性、隐私性或其他特性。
最近，我们看到以太坊钱包在改善用户体验、安全性和功能性方面取得了很大进展。这篇文章的目标是分享我对理想的以太坊钱包应具备的一些特性的看法。这并不是一个完整的清单；受我密码朋克倾向的影响，文章主要关注安全性和隐私性，在用户体验方面肯定还有所欠缺。然而，就优化用户体验而言，我认为制定愿望清单的效果不如实际部署并根据反馈进行迭代来得好。因此，我认为将重点放在安全性和隐私性特征上更为有价值。
跨 L2 交易的用户体验
现在已经有了一个越来越详细的跨 L2 用户体验改进路线图，包含短期和长期两个部分。在这里，我将讨论短期部分：即使在今天也在理论上可以实施的想法。
核心思想是：（i）内置跨 L2 发送功能，以及（ii）链特定地址和支付请求。你的钱包应该能够为你提供一个地址（按照这个 ERC 草案的风格），看起来像这样：
0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth
当某人（或某个应用程序）给你一个这种格式的地址时，你应该能够将其粘贴到钱包的"收款方"字段中，然后点击"发送"。钱包应该能够自动以任何可能的方式处理该笔发送：
- 如果你在目标链上已经有足够的所需代币，直接发送代币
- 如果你在另一条链上（或多条其他链上）有所需类型的代币，使用类似 ERC-7683的协议（实际上是一个跨链 DEX）来发送代币
- 如果你在同一条链或其他链上有不同类型的代币，使用 DEX 将它们转换成正确链上的正确代币类型并发送。这需要用户的明确许可：用户将看到他们支付的金额是多少，以及接收方获得多少。
支持跨链地址的钱包界面模拟图
上述内容是针对"你复制粘贴一个地址（或 ENS，例如 vitalik.eth@optimism.eth）让他人向你付款"的使用场景。如果某个 Dapp 请求存款（例如参见这个 Polymarket 示例），那么理想的流程是扩展 web3 API，允许 Dapp 发起特定链的支付请求。你的钱包随后可以通过任何必要的方式满足该请求。为了使用户体验良好，还需要标准化 getAvailableBalance 请求，而且钱包需要认真考虑默认将用户资产存储在哪些链上，以最大限度地提高安全性和转账便利性。
特定链的支付请求也可以放入二维码中，供移动钱包扫描。在面对面（或在线）消费支付场景中，接收方会生成一个二维码或发起 web3 API 调用，表示"我想在链Z上收到X单位的 Token Y，参考 ID 或回调为W"，而钱包可以通过任何可行的方式满足该请求。另一个选择是认领链接（claim link）协议，用户的钱包生成一个二维码或 URL，其中包含从其链上合约中认领特定数量资金的授权，接收方需要自行确定如何将这些资金转移到他们自己的钱包中。
另一个相关话题是 gas 费用支付。如果你在一个尚未持有 ETH 的 L2 上接收资产，且需要在该 L2 上发送交易，钱包应能自动使用协议（例如 RIP-7755）从你持有 ETH 的链上支付 gas 费用。如果钱包预计你未来会在该 L2 上进行更多交易，它还应该直接使用 DEX 转入数百万 gas 单位的 ETH，这样未来的交易就可以直接在那里支付 gas（因为这样更便宜）。
账户安全
我理解账户安全挑战的一种方式是：一个好的钱包应该在两个方面同时表现出色：（i）保护用户免受钱包开发者被黑客攻击或恶意行为的影响，以及（ii）保护用户免受自身错误的影响。
左侧的"mistakles"拼写错误是无意的。不过，看到它时我意识到这个错误恰好很适合这个语境，所以我决定保留它。
对此，我在过去十多年来一直倾向于采用社交恢复和多重签名钱包的解决方案，并配合分级访问控制。用户的账户有两层密钥：一个主密钥和 N 个守护者(guardians)秘钥（例如 N = 5）。主密钥能够执行低价值和非金融操作。执行以下操作需要大多数守护者的同意：（i）高价值操作，如转移账户中的全部资产，或（ii）更改主密钥或任何守护者。如果需要，可以允许主密钥通过时间锁执行高价值操作。
以上是一个基本设计，可以进行扩展。会话密钥(session keys)和类似 ERC-7715 的权限机制，可以帮助不同应用在便利性和安全性之间取得平衡。更复杂的守护者架构，比如在不同阈值设置不同的时间锁定期，可以帮助最大化合法账户恢复的成功率，同时最小化被盗风险。
谁或什么应该成为守护者？
对于处在经验丰富的加密用户社区中的资深加密用户来说，一个可行的选择是朋友和家人的密钥。如果你让每个人提供一个新的地址，那么就没有人需要知道其他人的身份——事实上，你的守护者甚至不需要知道彼此是谁。他们在背着你串通的可能性微乎其微。然而，对于大多数新用户来说，这个选择并不可行。
第二个选择是机构守护者：这些专业机构只有在获得其他确认后才会签署交易，比如确认码，或者对于高价值用户来说是视频通话等方式来验证请求确实来自于你本人。人们很早就尝试建立这样的机构，例如我在2013年对CryptoCorp的介绍。然而，这类机构至今仍未能在市场上站稳脚跟。
第三个选择是多个个人设备（例如手机、台式机、硬件钱包）。这种方式虽然可行，但对于经验不足的用户来说，设置和管理都相当困难。同时还存在设备同时丢失或被盗的风险，特别是当这些设备存放在同一位置时。
最近，我们开始看到更多基于 通行密钥（passkeys） 的钱包。这些密钥可以只在你的设备上备份，使其成为一种个人设备解决方案；或者在云端备份，这样它们的安全性就依赖于密码安全、机构和可信硬件假设的复杂混合体。实际上，虽然通行密钥对普通用户来说确实能提供更好的安全性，但仅靠它们还不足以保护用户的毕生积蓄。
幸运的是，通过 ZK-SNARKs，我们有了第四个选择：ZK 包装的中心化身份（ZK-wrapped centralized ID）。这类解决方案包括 zk-email、Anon Aadhaar、Myna Wallet 以及许多其他项目。基本上，你可以将多种形式的（企业或政府的）中心化身份转换为以太坊地址，只有通过零知识证明证明你拥有对应的中心化身份，才能用它发送交易。
有了这个补充，我们现在有了广泛的选择，而 ZK 包装的中心化身份独特地实现了"新手友好"。
要使其发挥作用，需要通过简化和集成的用户界面来实现：你应该能够直接指定想要使用"example@gmail.com"作为守护者，然后它应该自动在后台生成相应的 zk-email 以太坊地址。高级用户应该能够在开源的第三方应用程序中输入他们的电子邮件（可能还包括用于隐私保护的加盐值（salt value），该值将保存在该电子邮件中），并确认生成的地址是否正确。对于任何其他支持的守护者类型，都应该遵循相同的原则。
Safe 界面的概念图
需要注意的是，如今 zk-email 面临的一个实际挑战是其依赖于 DKIM 签名，这种签名使用的密钥每隔几个月就会轮换一次，而这些密钥本身并没有被任何其他权威机构签名。这意味着当前的 zk-email 除了对服务提供商的信任外，还需要额外的信任基础；如果 zk-email 在可信硬件内使用 TLSNotary 来验证更新后的密钥，这种信任依赖可以得到降低，但这仍然不是理想的解决方案。希望邮件服务提供商能够开始直接对其 DKIM 密钥进行签名。目前，我建议将 zk-email 用作一个守护者，但不要用作大多数守护者：切勿将资金存储在一个可能因 zk-email 系统故障而导致资金无法访问的设置中。
新用户和应用内钱包
新用户实际上并不希望在首次注册体验中输入大量的守护人。因此，钱包应该为他们提供一个非常简单的选项。一个自然的方案是采用三选二机制，即通过用户电子邮件地址的 zk-email 验证、存储在用户设备上的密钥（可以是通行秘钥）以及由服务提供商持有的备份密钥。随着用户变得更有经验或积累了更多资产，他们应该在适当的时候被提示添加更多的守护人。
应用程序中集成的钱包是必然趋势，因为那些希望吸引非加密资产用户的应用程序不想让用户同时下载两个新应用（应用程序本身和以太坊钱包）而造成困扰。然而，使用多个应用程序钱包的用户应该能够将所有钱包关联起来，这样他们就只需要管理一个"访问控制中心"。最简单的方法是采用分层方案，通过一个快速的"关联"过程，允许用户将其主钱包设置为所有应用内钱包的守护人。Farcaster 客户端 Warpcast 已经实现了这一功能：
默认情况下，您的 Warpcast 账户的恢复权限由 Warpcast 团队控制。不过，您可以"完全掌控"您的 Farcaster 账户，将恢复权限更改为您自己的地址。
保护用户免受诈骗和其他外部威胁
除了账户安全之外，当今的钱包在识别虚假地址、钓鱼、诈骗和其他外部威胁方面做了很多工作，并试图保护用户免受这些威胁。同时，许多防范措施仍然相当原始：例如，向任何新地址发送 ETH 或其他 Token 时都需要点击确认，无论你发送的是 100 美元还是 100，000 美元。在这方面，并不存在一个完美的解决方案；这是一系列针对不同类别威胁的持续缓慢修复和改进。然而，在这方面继续努力改进是非常有价值的。
隐私性
现在是时候开始更加认真地对待以太坊上的隐私问题了。ZK-SNARK 技术现已非常先进，像 Privacy Pools 这样无需依赖后门就能降低监管风险的隐私技术也日趋成熟，而像 Waku 和 ERC-4337 交易内存池这样的二级基础设施也正在逐步稳定。然而，到目前为止，在以太坊上进行隐私转账仍需要用户显式下载并使用"隐私钱包"，比如 Railway（或者使用 Umbra 来实现隐匿地址）。这增加了很大的不便，也减少了愿意进行隐私转账的人数。解决方案是需要将隐私转账直接集成到钱包中。
一个简单的实现方式如下：钱包可以将用户的部分资产作为"隐私余额"存储在隐私池中。当用户进行转账时，它会自动先从隐私池中提取。如果用户需要接收资金，钱包可以自动生成一个隐匿地址。
此外，钱包可以为用户参与的每个应用程序（例如 DeFi 协议）自动生成一个新地址。存款将来自隐私池，而提款将直接进入隐私池。这使得用户在任何一个应用程序中的活动都无法与其在其他应用程序中的活动建立联系。
这种技术的一个优势在于，它不仅为资产转移提供了隐私保护的自然途径，同时也为身份提供了隐私保护。身份验证已经在链上发生：任何使用实人认证门槛的应用（例如 Gitcoin Grants）、任何 Token 准入聊天、Ethereum Follow Protocol以及更多应用都是链上身份的体现。我们希望这个生态系统也能实现隐私保护。这意味着用户的链上活动不应该被集中存储在一处：每个项目都应该分开存储，而用户的钱包应该是唯一能够同时查看所有认证信息的"全局视角"。原生支持每个用户拥有多个账户的生态系统有助于实现这一目标，链下认证协议如EAS和Zupass也是如此。
这代表了以太坊在中期未来关于隐私保护的务实愿景。虽然现在就可以实施，但在L1和L2层面还可以引入一些功能，使隐私保护转账更加高效可靠。一些隐私倡导者认为，唯一可接受的方案是对所有内容实现完全隐私：即加密整个EVM。我认为这可能是理想的长期目标，但它需要对编程模型进行更加根本的重新思考，目前其成熟度还不足以在以太坊上全面部署。我们确实默认地获得隐私，来获得足够大的匿名性。然而，首先专注于实现（i）账户之间的转账，以及（ii）身份和与身份相关的场景（如认证）的隐私保护，是一个更容易实施的务实第一步，而且钱包可以立即着手进行。
以太坊钱包也需要成为数据钱包
任何有效的隐私解决方案，无论是用于支付、身份还是其他场景，其结果之一就是需要用户存储链下数据。这一点在 Tornado Cash 中表现得很明显，它要求用户保存代表 0.1-100 ETH 存款的每个独立"note"。更现代的隐私协议有时会在链上保存加密数据，并使用单个私钥来解密。这很危险，因为一旦密钥泄露，或者量子计算机变得可行，所有数据都会公开。像 EAS 和 Zupass 这样的链下证明对链下数据存储有着更明显的需求。
钱包需要不仅仅是存储链上访问权限的软件，还需要是存储个人私密数据的软件。非加密世界也越来越认识到这一点，例如，可以参见 Tim Berners-Lee 在个人数据存储方面的最新工作。我们需要解决的所有关于稳健保证访问权限控制的问题，也需要应用到稳健保证数据的可访问性和防泄漏方面。也许这些解决方案可以叠加在一起：如果你有 N 个守护者，可以使用需要其中 M 个守护者合作的方式来共同保管你的数据。数据本质上更难保护，因为你无法撤销某人对数据的共享，但我们应该设计出尽可能安全的去中心化托管解决方案。
链访问的安全性
如今，钱包完全信任其 RPC 提供商提供的任何链上信息。这在两个方面存在安全隐患：
RPC 提供商可能通过提供虚假信息来试图窃取资金，例如关于市场价格的信息
RPC 提供商可能窃取私人信息，了解用户正在与哪些应用程序和其他账户进行交互
理想情况下，我们希望能够解决这两个安全隐患。要解决第一个问题，我们需要为 L1 和 L2 标准化轻客户端，直接验证区块链共识。Helios 已经为 L1 实现了这一点，并且已经在进行一些支持特定 L2 的初步工作。为了妥善覆盖所有 L2，我们需要一个标准，通过这个标准，代表一个 L2 的Config contract(配置智能合约)（也用于特定链的地址）可以声明一个函数，也许采用类似于 ERC-3668 的方式，包含获取最新状态根以及验证状态和收据证明的逻辑。这样我们就可以拥有一个通用轻客户端，使钱包能够安全地验证 L1 和 L2 上的任何状态或事件。
对于隐私而言，目前唯一现实的方法是运行自己的全节点。然而，随着 L2 的加入，运行所有内容的全节点变得越来越困难。这里与轻客户端相对应的是私有信息检索（private information retrieval, PIR）。PIR 涉及一个服务器持有所有数据的副本，客户端向服务器发送加密请求。服务器对所有数据执行计算，将客户端所需的数据以客户端密钥加密的形式返回，而不向服务器透露客户端访问了哪条数据。
为了确保服务器的诚实性，各个数据库项本身都将是默克尔树分支，这样客户端就可以使用其轻客户端进行验证。
PIR 在计算上非常昂贵。有几种方法可以解决这个问题：
暴力方法：算法的改进或专用硬件可能使 PIR 运行得足够快。这些技术可能依赖于预处理：服务器可以为每个客户端存储加密并打乱的数据，客户端可以查询这些数据。在以太坊环境中的主要挑战是如何将这些技术适应于快速变化的数据集（如状态数据）。这种方法可以降低实时计算成本，但可能会增加总体计算和存储成本。
弱化隐私要求：例如，每次查询只有 100 万个"混淆项"，这样服务器只能知道客户端可能访问的 100 万个可能值，而无法获得更精确的信息。
多服务器 PIR：如果使用多个服务器，并在这些服务器之间采用"至少一个诚实"的假设，PIR 算法通常会快得多。
匿名性而非机密性：不是隐藏请求的内容，而是通过混淆网络发送请求，隐藏请求的发送者。然而，要有效地实现这一点必然会增加延迟，从而影响用户体验。
在以太坊环境中找出正确的技术组合以在保持实用性的同时最大化隐私是一个尚未解决的研究课题，我欢迎密码研究者们尝试解决这个问题。
理想的 keystore 钱包
除了转账和状态访问外，在跨 L2 环境中需要顺畅运行的另一个重要工作流程是更改账户的验证配置：无论是更改密钥（如恢复），还是对账户的整个逻辑进行更深层次的更改。在这里，有三个层次的解决方案，按难度递增排序：
重放更新(Replayed updates)：当用户更改其配置时，授权此更改的消息会在钱包检测到用户拥有资产的每条链上重放。可能的情况是，消息格式和验证规则可以做到与链无关，因此它可以在尽可能多的链上自动重放。
L1 上的 Keystores：配置信息存在于 L1 上，L2 上的钱包通过 L1SLOAD 或 REMOTESTATICCALL 读取它。这样，更新配置只需要在 L1 上进行一次，配置就会自动生效。
L2 上的 Keystores：配置信息存在于 L2 上，L2 上的钱包通过 ZK-SNARK 读取它。这与方案（2）相同，只是 Keystores 更新可能更便宜，但另一方面读取成本更高。
解决方案（3）特别强大，因为它可以很好地与隐私结合。在普通的「隐私解决方案」中，用户有一个秘密s，"叶子值"L在链上发布，用户证明对于他们控制的某个（从未公开的）秘密，L = hash(s, 1)且N = hash(s, 2)。nullifier N会被公布，确保同一叶子的未来支出会失败，而无需透露L。这取决于用户安全保管s。一个支持恢复的隐私解决方案则会说：s是链上的一个位置（例如地址和存储槽），用户必须证明一个状态查询：L = hash(sload(s), 1)。
Dapp 安全性
用户安全中最薄弱的环节通常是 Dapp。大多数情况下，用户通过访问网站与应用程序交互，这意味着要从服务器实时下载用户界面代码并在浏览器中执行。如果服务器被黑客入侵，或者 DNS 被劫持，用户就会获得一个虚假的界面副本，这可能会诱导用户执行任意操作。钱包的交易模拟等功能在降低风险方面很有帮助，但还远非完美。
理想情况下，我们应该将生态系统转向链上内容版本管理：用户通过 ENS 域名访问 Dapp，该域名包含界面的 IPFS 哈希值。更新界面需要多重签名或 DAO 发起的链上交易。钱包会向用户显示他们是在与更安全的链上界面交互，还是在与不太安全的 web2 界面交互。钱包还可以向用户显示他们是否在与安全的链（例如：第一阶段以上，多重安全审计）进行交互。
对于注重隐私的用户，钱包还可以添加"高安全模式"，该模式要求用户点击确认 HTTP 请求，而不仅仅是 web3 操作：
高安全模式可能的界面示意图
一个更先进的方法是超越 HTML + Javascript，使用专门的语言编写 Dapp 的业务逻辑，也许是在 Solidity 或 Vyper 之上的相对轻量级的封装。浏览器可以为任何需要的功能自动生成用户界面。OKContract 已经在这样做了。
另一个方向是加密经济信息防御（cryptoeconomic info-defense）：去中心化应用开发者、安全公司、链部署方和其他主体可以提供一笔保证金，如果应用被黑客攻击或以极具误导性的方式损害用户利益，经由某个链上仲裁 DAO 确认后，这笔保证金将支付给受影响的用户。钱包可以向用户展示一个基于保证金规模的评分。
更长远的未来
以上所述都是在传统界面的背景下，即点击和在文本框中输入内容。然而,我们也正处在范式发生深刻变革的临界点上：
- 人工智能（AI），这可能使我们从"点击和输入"的范式转向"说出你想做什么，让机器人来解决"的范式
- 脑机接口（Brain-computer interfaces），包括眼动追踪等"温和"方法以及更直接甚至侵入性的技术（参见：今年首位 Neuralink 患者）
- 客户端主动防御：Brave 浏览器主动保护用户免受广告、追踪器和其他不良对象的影响。许多浏览器、插件和加密钱包都有专门的团队在积极努力保护用户免受各种安全和隐私威胁。这类"主动守护者"在未来十年将变得更加强大。
这三个趋势的结合将引发对用户界面如何工作的更深层次的重新思考。通过自然语言输入、眼动追踪，或最终更直接的脑机接口，再加上对你历史记录的了解（可能包括短信，只要所有数据都在本地处理），"钱包"可以清晰直观地理解你想做什么。人工智能随后可以将这种直觉转化为具体的"行动计划"：一系列实现你目标的链上和链下交互。这可能大大减少对第三方用户界面的需求。
如果用户确实要与第三方应用程序（或其他用户）进行交互，人工智能应该扮演用户的守护者角色，识别任何威胁并提出避免这些威胁的行动计划。理想情况下，这些人工智能将形成一个开放的生态系统，由具有不同偏好和激励结构的不同群体开发。
这些更为激进的想法依赖于当今极其不成熟的技术，因此我目前不会将资产存入依赖这些技术的钱包中。然而，这种技术发展方向似乎明显代表着未来趋势，值得我们开始更积极地朝这个方向探索。