本文讨论了理想的以太坊钱包应具备的特性,强调安全性、隐私和用户体验的重要性。文章提出了一些增强跨L2交易、账户安全以及用户防范外部威胁的建议,同时还探讨了如何利用ZK-SNARKs等技术来改善钱包的隐私保护和安全性。最后,阐述了钱包未来发展的可能趋势,包括AI与脑机接口的应用。
我希望在钱包中看到的功能
特别感谢 Liraz Siri、Yoav Weiss,以及 ImToken、Metamask 和 OKX 开发者的反馈与评审。
以太坊基础设施堆栈中一个关键的组成部分,往往未被 L1 核心研究者和开发者所重视,就是钱包。钱包是用户与以太坊世界之间的窗口,用户仅在钱包本身具备去中心化、抗审查、安全、隐私或以太坊及其应用程序提供的其他特性时,才能享受到这些特性所带来的好处。
最近,我们看到在提升以太坊钱包的用户体验、安全性和功能方面有了很多进展。本文的目标是分享我对理想以太坊钱包所应具备的一些特性的看法。这不是一个完整的列表;由于我的网络朋克倾向,它更多地关注于安全性和隐私,用户体验方面几乎肯定是不完整的。然而,我认为愿望清单在优化用户体验方面并不如直接基于反馈部署与迭代有效,因此我认为关注安全性和隐私特性是最有价值的。
现在,改善跨 L2 用户体验的路线图越来越详细,这包括短期部分和长期部分。在这里,我将谈论短期部分:理论上即使在 今天 也可以实现的想法。
核心想法是 (i) 内置的跨 L2 发送,以及 (ii) 链特定地址和支付请求。你的钱包应该能够提供一个地址,如以下格式 (遵循 这个草案 ERC):
0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth
当某人(或某个应用程序)给你一个这种格式的地址时,你应该能够将其粘贴到钱包的“收款人”字段中,然后点击“发送”。钱包应该以能处理的任何方式自动处理此发送:
以上是针对“你复制粘贴一个地址(或 ENS,例如 vitalik.eth@optimism.eth)供别人支付给你”的使用案例。如果某个 dApp 请求存款(例如,请参阅 这个 Polymarket 示例),那么 理想 的流程是扩展 web3 API,允许 dApp 发出链特定的支付请求。然后,你的钱包将能够以它所需的任何方式满足该请求。使用户体验良好也需要标准化 getAvailableBalance 请求,钱包需要认真考虑默认将用户资产存储在哪些链上,以最大程度地提高安全性和转移的便捷性。
链特定的支付请求也可以放入 QR 代码中,移动钱包可以扫描。在面对面的(或在线)消费者支付场景中,接收者会生成一个 QR 代码或 web3 API 调用,表明“我想要链 Z
上代币 Y
的 X
单位,参考 ID 或回调为 W
”,钱包可以以能满足该请求的任何方式处理。另一种选择是 认领链接 协议,用户的钱包生成一个 QR 代码或 URL,包含授权以从其链上合约中认领一定数量的资金,而接收者的任务是弄清楚如何将这些资金转移到他们自己的钱包中。
另一个相关话题是Gas费用支付。如果你在一个 L2 收到资产,但你尚未拥有 ETH,并且需要在该 L2 上发送交易,钱包应该能够自动使用某个协议(例如 RIP-7755)在你 已经 拥有 ETH 的链上支付Gas。如果钱包预计你在未来会在该 L2 上进行更多交易,它还应该使用 DEX 发送例如几百万的 ETH 用于Gas,从而让未来的交易可以直接使用该链上的Gas(因为这样更便宜)。
我对账户安全挑战的一个概念是,一个良好的钱包应该同时在两个领域表现良好:(i)保护用户免受钱包开发者被黑或恶意行为的影响,以及(ii)保护用户免于自己的错误。
我对此的首选解决方案,在 超过 十年的 时间里,一直是社会恢复和多重签名钱包,附带分级访问控制。用户的账户有两层密钥:一个主密钥,以及 N 个监护者(例如 N = 5)。主密钥能够进行低价值和非金融操作。大多数监护者的同意是执行(i)高价值操作(如转走账户中的全部价值),或(ii)更改主密钥或任何监护者所必需的。如果需要,主密钥可以在设定时间锁的情况下执行高价值操作。
上述是一个基本设计,可以进行增强。会话密钥,以及像 ERC-7715 一样的权限机制,可以帮助在便利性和安全性之间实现不同的平衡。更复杂的监护者架构,如在不同阈值设置多个时间锁持续时间,可以帮助最大限度地提高成功合法账户恢复的机会,同时将盗窃风险降至最低。
对于一个经验丰富的加密用户,在一个经验丰富的加密用户群体中,一个可行的选择是你朋友和家人的密钥。如果你要求每个人都提供一个新地址,那么没有人需要知道他们是谁——实际上,你的监护者甚至不需要知道彼此是谁。他们在没有一个人向你通风报信的情况下,共同作恶的概率非常小。然而,对于大多数新用户而言,这个选择是不可用的。
第二个选择是机构监护者:专门负责在收到你请求的某种其他确认后才签署交易的公司:例如确认码,或者对于高价值用户进行视频通话。人们努力做这些工作已经很久了,例如 2013 年我对 CryptoCorp 进行了介绍。然而,到目前为止,这些公司并没有取得很大成功。
第三个选择是多个个人设备(例如手机、桌面电脑、硬件钱包)。这可以工作,但对于经验不足的用户来说也很难设置和管理。同时也面临丢失或盗取设备的风险,尤其是在同一地点。
最近,我们开始看到更多基于 passkeys 的钱包。Passkeys 只能在用户的设备上进行备份,使其成为一种个人设备解决方案,或者在云中备份,因此其安全性依赖于一种 复杂 混合 的密码安全、机构和可信硬件假设。现实中,passkeys 对普通用户来说是一个很大的安全收益,但仅靠它们不足以保护用户的终身储蓄。
幸运的是,借助 ZK-SNARKs,我们有了第四个选择:ZK-包装的中心化 ID。这个类型包括 zk-email、Anon Aadhaar、Myna Wallet,以及许多其他选项。基本上,你可以将许多形式的(公司或政府的)集中 ID 转换为一个以太坊地址,而你只能通过生成 ZK-SNARK 证明拥有该集中 ID 来发送事务。
通过这个补充,我们现在有了多种选择,而 ZK-包装的中心化 ID 对新手级别的用户来说特别友好。
为了使这一切顺利进行,需要通过一个简化和集成的用户界面进行实现:你应该能够简单地指定你想要“example@gmail.com”作为监护者,它应该自动在后台生成相应的 zk-email 以太坊地址。高级用户应该能够将他们的电子邮件(或许还有一个为了隐私而保存的盐值)输入到一个开源的第三方应用程序中,并确认生成的地址是正确的。对任何其他支持的监护者类型应一律如此。
请注意,如今,zk-email 特有的一个实际挑战是,它依赖 DKIM 签名,这些密钥每几个月就会轮换一次,而这些密钥本身并未得到任何其他机构的签名。这意味着当前 zk-email 在某种程度上需要超出提供商本身的信任需求;如果 zk-email 能在受信硬件内使用 TLSNotary 验证更新密钥,这可以降低这种信任要求,但仍然不理想。希望邮件服务提供商将开始直接签署他们的 DKIM 密钥。现在,我建议 zk-email 用作一个监护者,但不要作为大多数监护者:不要将资金存储在 zk-email 出现故障将导致你失去资金访问权限的设置中。
新用户实际上并不想在他们的 首次注册体验 中输入大量监护者。因此,钱包应该提供非常简单的选择。一种自然的途径是通过 zk-email 对电子邮件地址使用 2-of-3,这是一个保存在用户设备上的密钥(可以是一个 passkey),以及由服务提供商持有的备份密钥。随着用户变得更加熟练或积累更多资产,某个时候应该提示他们添加更多监护者。
集成在应用内的钱包 是不可避免的,因为旨在吸引非加密用户的应用不想让他们的用户在同一时间下载 两个新应用(此应用程序本身以及以太坊钱包)带来困惑的用户体验。然而,许多应用程序钱包的用户应该能够将他们的所有钱包互相链接,这样他们只需担心一个“访问控制”即可。最简单的方式是采用分层方案,设置一个快速的“链接”过程,使用户能够将其主钱包设置为所有应用内钱包的监护者。Farcaster 客户端 Warpcast 已经支持这一点:
除了账户安全,钱包现在在识别虚假地址、网络钓鱼、诈骗和其他外部威胁方面做了很多工作,并尽量保护用户免受此类威胁。同时,许多对策仍然相当原始:例如,要求在向 _任何_新地址(无论是发送 $100 还是 $100,000)时都需点击确认。在这里,没有单一的万灵药解决方案;这是一系列缓慢的、持续的修复和改进,以应对不同类别的威胁。然而,在继续努力改进这一点方面,存在巨大的价值。
现在是时候更加认真地对待以太坊上的隐私了。ZK-SNARK 技术现在非常先进,能够减轻监管风险的隐私技术,例如 Privacy Pools 也正在逐渐成熟,二级基础设施,例如 Waku 和 ERC-4337 mempools 正在慢慢变得更加稳定。然而,到目前为止,在以太坊上进行私人转账需要用户明确下载和使用“隐私钱包”,例如 Railway(或 Umbra 用于 隐匿地址)。这增加了极大的不便,并减少了愿意进行私人转账的人数。解决方案是: 私人转账需要直接集成到钱包中。
一个简单的实现如下。钱包可以将用户的某部分资产存储为隐私池中的“私有余额”。当用户进行转账时,系统将自动从隐私池中提取。如果用户需要接收资金,钱包可以自动生成一个隐匿地址。
此外,钱包可以为用户参与的每个应用程序自动生成一个新地址(例如,一个 DeFi 协议)。存款来自隐私池,而取款则直接进入隐私池。这使得用户在任何一个应用中的活动与他们在其他应用中的活动没有关联。
这种技术的一个优势是,它自然而然地为不仅仅是隐私保护的 资产转移 提供了一条途径,还是隐私保护的 身份。身份已经在链上存在:任何使用身份证明门控(例如 Gitcoin Grants)的应用程序,任何基于代币的聊天室,以太坊跟随协议 等等,都是链上身份。我们希望这个生态系统也能保护隐私。这意味着用户在链上的活动不应该集中存储在一个地方:每个项目都应该单独存储,用户的钱包应该是唯一一个具有“全局视图”的实体,能够同时看到你所有的认证。一个本质上支持每个用户多帐户的生态系统有助于实现这一目标,链下认证协议如 EAS 和 Zupass 也是如此。
这代表了对以太坊隐私的中期现实主义愿景。今天可以实现这个,尽管可以在 L1 和 L2 引入一些功能以使隐私保护转账更加高效和可靠。一些隐私倡导者认为,唯一可接受的事情是所有事务的完全隐私:加密整个 EVM。我认为这可能是一个长期理想结果,但这需要对编程模型做更根本的重新思考,目前的成熟度尚未达到足以在以太坊上全面复制和部署的水平。我们确实需要默认隐私,以获得足够大的匿名集。然而,首先关注使 (i) 账户间转账和 (ii) 身份及与身份相关的使用案例(如认证)保持私密,是一个务实的第一步,更容易实现,钱包也可以今天开始着手。
任何有效的隐私解决方案,无论是针对支付还是身份或其他用例,都意味着用户需要存储链外数据。这在 Tornado Cash 中非常明显,它要求用户保存每个单独的“凭证”,代表 0.1-100 ETH 的存款。更现代的隐私协议有时将数据加密存储在链上,并使用单一的私钥进行解密。这是有风险的,因为如果密钥泄露,或者如果量子计算机变得可行,所有数据都将公开。链下证明(如 EAS 和 Zupass)更明显地需要链外数据存储。
钱包不仅需要成为存储链上访问权限的软件,还需要成为存储你的私有数据的软件。这一点在非加密世界也越来越受到认可,例如,看看 Tim Berners-Lee 最近在个人数据存储方面的 工作。我们需要解决的关于稳健保障访问权限的控制的所有问题,也需要确保数据的可访问性和不泄漏的可靠性。也许解决方案可以结合在一起:如果你有 N 个监护者,使用 M-of-N 秘密共享在这 N 个监护者之间存储你的数据。数据本质上更难以安全保护,因为你无法撤销某人的分享,但我们应该想出尽可能安全的去中心化保存解决方案。
如今,钱包信任其 RPC 提供商以获取有关链的任何信息。这在两个方面都是一个漏洞:
理想情况下,我们希望堵住这两个漏洞。为了封堵第一个,我们需要对 L1 和 L2 标准化轻客户端,从而直接验证区块链共识。 Helios 已经对 L1 进行了这一操作,并且已经开始针对某些特定的 L2 提供初步支持。为了真正覆盖所有 L2,我们需要一个标准,通过 配置合约 表示 L2(该合约同样用于链特定地址),可以声明一个函数,或许类似于 ERC-3668,包含获取最近状态根的逻辑,并验证状态和收据的证明是否与这些状态根一致。通过这种方式,我们可以拥有一个 通用轻客户端,使钱包能够安全地验证 L1 和 L2 上的任何状态或事件。
在隐私方面,目前唯一现实的方法是运行自己的全节点。然而,随着 L2 的引入,运行所有内容的全节点变得越来越困难。这里的轻客户端等同于 私人信息检索 (PIR)。PIR 涉及一个服务器持有所有数据的副本,一客户端向服务器发送加密请求。服务器在所有数据上执行计算,返回客户端所需的数据,以客户端的密钥加密,而不向服务器透露客户端访问了哪部分数据。
为了保持服务器诚实,单个数据库项本身应该是默克尔分支,这样客户端就可以使用轻客户端进行验证。
PIR 消耗计算量大。有几种解决此问题的路线:
在以太坊的背景下,确定最大化隐私的技术组合,同时保持实用性是一个开放的研究问题,我欢迎密码学家对此进行尝试。
除了转账和状态访问外,在跨 L2 上下文中,另一个重要的工作流程是更改账户的验证配置:无论是更改密钥(例如,恢复)还是更深入地改变账户所有逻辑。在这里,有三个层次的解决方案,按难度递增排序:
解决方案(3)尤其强大,因为它与 隐私 叠加得很好。在正常的“隐私解决方案”中,用户拥有一个秘密 s
,一个“叶值” L
被发布在链上,用户证明 L = hash(s, 1)
和 N = hash(s, 2)
对于某个(从未透露的)他们所控制的秘密。nullifier N
被发布,确保相同叶值的未来支出失败,同时又不泄露 L
。这需要用户保持 s
的安全。一个 适合恢复的 隐私解决方案将相应地说:s
是一个 位置(例如链上的地址和存储槽),用户必须证明某个状态查询:L = hash(sload(s), 1)
。
用户安全性最薄弱的环节往往是 dApp。用户通常通过访问一个网站与应用程序进行交互,该网站在实时从服务器下载用户界面代码并在浏览器中执行。如果服务器被黑,或 DNS 被黑,用户将会得到一个假冒的界面,这可能会使用户做出任意操作。钱包的交易模拟功能对于降低风险非常有帮助,但远非完美。
理想情况下,我们希望将生态系统迁移到链上内容版本控制:用户应该通过其 ENS 名称访问 dApp,该名称将包含界面的 IPFS 哈希。需要多签或 DAO 的链上交易来更新接口。钱包将向用户显示他们是否在与更安全的链上接口互动,或是在与较不安全的 Web2 接口互动。钱包还可以向用户显示他们是否在与一个安全的 链 (例如,第 1 阶段+,经过多次安全审计)进行互动。
对于关注隐私的用户,钱包还可以加入 偏执模式,要求用户点击确认 HTTP 请求,而不仅仅是 web3 操作:
更高级的方法将是超越 HTML + Javascript,以专门的语言编写 dApp 的业务逻辑,也许是相对精简的 Solidity 或 Vyper 上层。浏览器可以自动为所需的任何功能生成用户界面。OKContract 已经开始这么做。
另一个方向是 加密经济信息防御:dApp 开发者、安全公司、链部署者和其他人可以提供一笔保证金,如果 dApp 被黑或以其他方式以严重误导用户的方式行为,从而使受影响的用户获得赔偿,该行为的定性将交由某个链上裁决 DAO 决定。钱包可以向用户展示一个基于保证金大小的评分。
以上所有内容都在常规接口的背景下,那涉及到指向、点击事物并在文本框中输入内容。然而,我们也处于更根本性范式变化的边缘:
这三种趋势将促使我们对接口的工作原理进行更深入的思考。通过自然语言输入、眼动追踪,或最终更直接的脑机接口,以及对你的历史的了解(或许包括文本消息,只要所有数据都在本地处理),一个“钱包”可以清楚地直观理解你想做的事情。然后,AI 可以将这种直觉转化为具体的“行动计划”:一系列实现你目标的链上和链下交互。这可能极大地减少对第三方用户界面的需求。如果用户 确实 与第三方应用程序(或另一个用户)互动,AI 应该在用户的立场上进行对抗性思维,识别任何威胁,并提出避免它们的行动计划。理想情况下,将会存在一个由不同群体、具有不同偏见和激励结构生成的开放生态系统的 AI。
这些更激进的想法依赖于当前 极其 幼稚的技术,因此我今天不会将我的资产保存在依赖于它们的钱包中。然而,这样的事物似乎明显是未来,因此值得开始更积极地朝这个方向探索。
- 原文链接: vitalik.eth.limo/general...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!