跨L2交易的用户体验

目前，已有越来越明确的路线图来改善跨L2的用户体验，这个路线图分为短期和长期两个阶段。这里我们主要讨论短期部分，也就是理论上今天就可以实现的功能。核心思路包括：（i）内建跨L2发送功能，（ii）链特定地址和支付请求。钱包应该能够为用户生成类似以下格式的地址（遵循该草案ERC的格式）：0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth \
当有人（或应用）给您这样一个地址时，您应该能把它粘贴到钱包的“收款”字段中，并点击“发送”按钮。钱包应当自动按以下方式处理转账：

• 如果目标链上已有足够的代币，直接发送；
• 如果所需代币在其他链上（或多个链上），可以通过类似ERC-7683的协议（其实是一个跨链去中心化交易所）进行转账；
• 如果所需代币在同一链或其他链上存在不同类型，钱包应通过去中心化交易所将其转换为正确类型的代币并发送。此操作需要得到用户的明确授权：用户会看到他们支付了多少代币，以及接收方最终收到多少代币。

支持跨链地址的可能钱包界面原型：

上述内容适用于“用户复制粘贴地址（或ENS，例如vitalik.eth@optimism.eth）供他人付款”的场景。如果某个Dapp请求存款（例如Polymarket），理想的流程是扩展web3API，允许Dapp发起链特定的支付请求，钱包则能够按照需要满足这些请求。为了优化用户体验，还需要标准化“获取可用余额”的请求，钱包需要仔细考虑默认在哪些链上存储用户的资产，以确保既能保障安全性，又能方便用户进行转账。

链特定支付请求还可以通过二维码的方式进行传递，用户使用移动钱包扫描二维码后即可完成支付。在面对面（或在线）支付场景中，收款方可以生成二维码或通过web3API发出请求，说明“我需要链Z上的X单位Y代币，参考ID或回调W”，钱包应当能够根据实际情况满足这个请求。另一种方式是索赔链接协议，用户钱包生成一个二维码或URL，其中包含授权从链上的合约提取一定数量资金的信息，接收方则需要自己将这些资金转移到自己的钱包。

如果用户在一个L2上收到了资产，但没有ETH，并且需要在该L2上发送交易，钱包应能够通过某种协议（例如RIP-7755）自动在用户拥有ETH的链上支付燃气费。如果钱包预计用户将来还会在该L2上进行更多交易，钱包还应使用DEX将一定数量的ETH（例如几百万燃气费值的ETH）转移到L2，以便未来的交易可以直接在L2上支付燃气费，这样做更加节省成本。

账户安全

我对账户安全挑战的理解是，一个优秀的钱包应在两个方面表现出色：（i）保护用户免受钱包开发者的黑客攻击或恶意行为的影响；（ii）保护用户免受自身错误的影响。

左侧“mistakles”的拼写错误并非故意为之，但看到后，我意识到这正好符合语境，因此决定保留这一错误。

十多年来，我偏爱的解决方案是社交恢复和多签钱包，并结合分级访问控制。用户的账户有两层密钥：一是主密钥，二是N个监护人（如N=5）。主密钥可以执行低价值且非金融的操作；而进行高价值操作（比如转走账户内的全部资产）或更改主密钥及任何监护人时，则需要大多数监护人的同意。如果需要，主密钥还可以通过设置时间锁来执行高价值操作。

以上是一个基础设计，可以进行扩展。比如会话密钥和类似ERC-7715的权限机制可以帮助在不同应用中平衡便利性与安全性。更复杂的监护人架构，如根据不同的阈值设置多个时间锁周期，能帮助最大化合法账户恢复的成功率，同时最小化盗窃风险。

监护人应该是谁？

对于有经验的加密用户，尤其是身处一个加密社区中的用户，有一个可行的方案是利用朋友和家人的密钥。如果要求每个监护人提供一个新的地址，那么他们彼此之间无需知道对方是谁——事实上，他们甚至无需知道彼此的身份。只要其中一个不泄密，串通的几率几乎为零。然而，对于大多数新用户来说，这种方式并不可行。

第二种选择是机构监护人：这些公司专门提供服务，仅在获得某种确认后才会签署交易，比如通过确认码或视频通话来验证用户身份。很多人尝试过这种方式，例如我在2013年就对 CryptoCorp 进行了介绍。然而，至今为止，这类公司并没有取得太大的成功。

第三种选择是使用多个个人设备（如手机、桌面和硬件钱包）。这种方式可行，但对缺乏经验的用户来说，设置和管理起来会比较复杂。而且，一旦设备丢失或被盗，尤其是当多个设备位于同一位置时，风险就会加大。

最近，我们开始看到越来越多的基于密码钥匙的钱包。密码钥匙可以仅在用户设备上备份，作为一种个人设备解决方案；或者可以备份到云端，从而使其安全性依赖于密码安全、机构以及受信硬件等复杂的混合因素。事实上，对于普通用户来说，密码钥匙无疑是一项重要的安全提升，但它们单独并不足以保护用户的全部资产。

幸运的是，借助ZK-SNARKs技术，我们有了第四种选择：ZK封装的集中式身份。这一方案包括 zk-email, Anon Aadhaar, Myna Wallet 等。基本上，您可以将不同形式的（公司或政府提供的）集中式身份转换为以太坊地址，而该地址只能通过生成ZK-SNARK来证明拥有该身份后，才能进行交易。

有了这一新选择，我们现在有了更多的解决方案，其中ZK封装的集中式身份特别适合新手用户。

为了使这一方案有效运行，需要具备流畅、集成的用户界面：用户应该能够简单地指定像“example@gmail.com”这样的电子邮件作为监护人，系统后台自动生成对应的zk-email以太坊地址。高级用户也应能将自己的电子邮件（以及可能的盐值）输入开源第三方应用中，确认生成的地址是正确的。其他任何支持的监护人类型也应当提供类似的操作方式。

可能的Safe界面原型：

需要注意的是，当前zk-email面临的一个实际问题是，它依赖DKIM签名，而这些签名的密钥会每隔几个月旋转一次，而且这些密钥并未由其他权威机构签署。这意味着zk-email目前需要在提供商本身之外，依赖一些额外的信任机制；如果zk-email能够使用TLSNotary在受信硬件中验证更新后的密钥，这个问题可能得到缓解，但仍然不是最理想的解决方案。希望未来电子邮件提供商能够开始直接签署DKIM密钥。目前，我建议将zk-email作为监护人使用，但不要将其作为多数监护人的选择：不要在zk-email一旦失效时，会导致您失去访问资金的场景下存储资金。

新用户和应用内钱包

新用户在首次注册时通常不愿意输入大量监护人信息，因此钱包应为他们提供一个简单的选择。一个自然的方案是使用zk-email作为其电子邮件地址的监护人，再加上本地存储在设备上的密钥（如密码钥匙），以及由服务提供商持有的备份密钥，构成一个2-of-3的解决方案。当用户的经验积累或资产增多时，他们应该被提示增加更多的监护人。

集成到应用内的钱包是不可避免的，因为大多数旨在吸引非加密用户的应用不希望让用户在同一时间下载两个新应用（应用本身和以太坊钱包）。然而，使用多个应用钱包的用户应该能够将所有钱包链接在一起，这样他们只需要关注一个“访问控制”的问题。最简单的方式是采用分层方案，让用户能够通过一个快速的“链接”过程，将主钱包设置为所有应用内钱包的监护人。Farcaster客户端Warpcast已经支持这一功能：

默认情况下，您的Warpcast账户恢复由Warpcast团队控制。但您可以选择“夺回主权”，将恢复设置为您自己的地址。

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

除了账户安全之外，今天的钱包在识别虚假地址、钓鱼攻击、诈骗和其他外部威胁方面已经做了大量工作，尽力保护用户免受这些威胁。然而，许多防范措施仍然较为原始。例如，在向任何新地址发送ETH或其他代币时，无论金额是100美元还是10万美元，都需要用户点击确认。这里并没有一个单一的解决方案，而是一个对不同类型威胁进行持续修复和改进的过程。不过，继续致力于改进这些防范措施，仍然具有非常重要的意义。

迈向以太坊的隐私新时代

现在是时候更加认真地对待以太坊上的隐私保护了。随着ZK-SNARK技术的不断发展，不依赖后门的隐私技术，如隐私池（Privacy Pools）也在不断成熟，而像Waku和ERC-4337 mempools等二级基础设施也在逐渐变得更加稳定。然而，直到现在，在以太坊上进行私密转账仍然需要用户明确下载并使用“隐私钱包”，如 Railway（或用于隐匿地址的Umbra）。这种额外的步骤带来了很大的不便，降低了愿意进行私密转账的用户数量。为了解决这个问题，私密转账应该直接集成到钱包中。

一种简单的实现方案如下：钱包可以将用户资产的一部分存储为“私密余额”，并将其存放在隐私池中。当用户进行转账时，钱包会自动优先从隐私池中提取资金。如果用户需要接收资金，钱包可以自动生成一个隐匿地址。

此外，钱包还可以为每个用户参与的应用自动生成一个新的地址（例如，一个去中心化金融协议）。存款会来自隐私池，而取款则直接返回隐私池。这样，用户在某个应用中的活动就能与在其他应用中的活动解绑。

这种技术的一个优势是，它不仅是保护资产转移隐私的自然路径，也是隐私保护身份的途径。身份本身就在链上：任何使用身份认证的应用（如Gitcoin Grants）、任何令牌限制的聊天、以太坊Follow协议等等，都是链上的身份数据。我们希望这个生态系统也是隐私保护的，这意味着用户的链上活动不应集中存储，而应分别存储。用户的钱包将成为唯一可以“全局查看”用户所有认证的地方。多账户生态和链下认证协议（如EAS和Zupass）有助于实现这一目标。

这代表了以太坊隐私的中期愿景。尽管今天就可以实施这一方案，L1和L2上也可以引入一些功能，以提高隐私保护转账的效率和可靠性。一些隐私倡导者认为，唯一可接受的方案是对所有内容进行完全隐私保护，即加密整个EVM。我认为，尽管这是一个理想的长期目标，但它要求我们对编程模型进行更根本的重新思考，目前的技术成熟度还不足以在以太坊上大规模部署。我们确实需要“隐私默认”来实现足够大的匿名性集。然而，首先关注让（i）账户间转账和（ii）身份及相关认证等使用案例保持私密，是更为务实的一步，这比完全加密EVM更容易实现，并且钱包可以立即开始使用。

以太坊钱包需转型为数据钱包

任何有效的隐私解决方案（无论是支付、身份还是其他使用场景）都将不可避免地需要用户存储链下数据。这一点在Tornado Cash中非常明显，它要求用户保存每个代表0.1-100 ETH存款的“票据”。更现代的隐私协议有时会将数据加密存储在链上，并使用单一的私钥来解密。这是有风险的，因为一旦密钥泄露，或者量子计算机变得可用，所有的数据都将公开。链下认证（如EAS和Zupass）则更明显地需要链下数据存储。

因此，钱包不仅需要成为存储链上访问权限的软件，还需要成为存储私密数据的软件。这一点在非加密世界中也在日益得到认识，例如蒂姆·伯纳斯·李（Tim Berners-Lee）最近在个人数据存储方面的工作。我们在解决确保访问权限控制的问题时，也需要解决如何确保数据的可访问性和防泄露问题。或许这些解决方案可以叠加：如果您有N个监护人，可以使用M-of-N秘密分享方法，在这些监护人之间存储数据。数据本身比密钥更难保护，因为一旦分享者拥有数据的某一份额，就无法撤销其访问权限，但我们仍然应该提出尽可能安全的去中心化托管解决方案。

安全链访问

今天，钱包依赖其RPC提供者来获取链上的信息。这在两个方面都存在漏洞：

1. RPC提供者可能试图通过提供虚假信息（例如市场价格）来窃取资金。
2. RPC提供者可能会提取用户与哪些应用或账户交互的私密信息。

理想的情况是，我们可以填补这两个漏洞。为此，我们需要标准化的L1和L2轻客户端，它们能够直接验证区块链共识。Helios已经实现了L1的轻客户端，并为一些特定的L2进行了初步支持。为了全面支持所有L2，我们需要一个标准，使得代表L2的配置合约（也用于链特定地址）能够声明一个函数，可能类似于ERC-3668，包含获取最新状态根的逻辑，并验证相应的状态证明和收据。这样，我们可以拥有一个通用的轻客户端，使钱包能够安全地验证L1和L2上的任何状态或事件。

对于隐私而言，当前唯一现实可行的方法是运行自己的完整节点。然而，随着L2的引入，运行每一个链的完整节点变得越来越困难。类似于轻客户端的做法是私密信息检索（PIR）。PIR涉及到一个服务器持有所有数据的副本，客户端向该服务器发送加密请求。服务器对所有数据进行计算，并返回加密后的所需数据，而不会泄露客户端访问的是哪一部分数据。

为了保持服务器的诚信，个别数据库条目本身将是Merkle分支，客户端可以使用其轻客户端进行验证。PIR的计算成本非常高。目前有几种解决方案可以应对这个问题：

• 暴力破解：通过算法改进或专用硬件，PIR可能足够快速运行。这些技术可能依赖预处理：服务器可以为每个客户端存储加密和洗牌过的数据，客户端可以查询这些数据。Ethereum场景中的主要挑战是如何将这些技术应用到快速变化的数据集（如区块链状态）中。
• 降低隐私要求：例如，每次查找只能有100万个“混合项”，服务器将知道客户端可能访问的100万个值，而无法知道更精细的内容。
• 多服务器PIR：如果使用多个服务器，PIR算法通常更快速，且服务器之间的诚信假设为1-of-N。
• 匿名性而非机密性：我们可以通过混合网络（mixnet）隐藏请求的发送者，而不是隐藏请求的内容。然而，这样做会不可避免地增加延迟，从而影响用户体验。

如何在以太坊环境中找到平衡隐私和实用性的正确技术组合，仍然是一个开放的研究问题，我欢迎密码学家们来尝试解决。

理想的密钥存储钱包

除了资产转移和状态访问，另一个需要在跨L2环境中流畅运行的重要工作流是更改账户的验证配置。无论是更换密钥（例如账户恢复），还是对账户的整体逻辑进行更深层次的修改，都需要考虑合适的解决方案。这里有三种解决方案，它们按从简单到复杂的顺序排列：

1. 重播更新：当用户更改配置时，授权此更改的信息会在钱包检测到用户持有资产的每条链上重播。通过设计链独立的信息格式和验证规则，可以让此消息自动在多个链上重播，从而简化操作。
2. L1上的密钥存储：将配置信息存储在L1上，L2上的钱包通过L1SLOAD或者REMOTESTATICCALL读取。这样，更新配置只需在L1上进行，且更新会自动在L2上生效。
3. L2上的密钥存储：将配置信息存储在L2上，L2上的钱包通过ZK-SNARK读取。这种方式与方案2类似，但由于密钥更新的成本更低，虽然读取成本更高，依然具有较强的灵活性。

其中，方案3尤其强大，因为它与隐私保护功能兼容，能够有效地保护用户的隐私。在常规的隐私解决方案中，用户拥有一个秘密值s，链上发布一个“叶子值”L，用户需要证明L = hash(s, 1)以及N = hash(s, 2)，其中s是从未公开的秘密值。发布的无效值N确保同一叶子值的未来消费会失败，而不会暴露L。这种方法的安全性依赖于用户妥善保管秘密s。如果使用支持恢复的隐私解决方案，则s会是链上的某个位置（如地址和存储槽），用户必须证明通过查询该位置的状态，计算得出L = hash(sload(s), 1)。

去中心化应用（Dapp）安全

用户的安全性往往受到Dapp的影响。大部分时间，用户通过浏览器访问一个网站与应用程序交互，而这个网站会实时从服务器加载用户界面代码并在浏览器中执行。如果服务器或DNS被攻击，用户可能会看到伪造的界面，从而被诱导执行错误操作。尽管钱包提供的交易模拟功能能在一定程度上降低这种风险，但它仍然不够完美。

理想的做法是，整个生态系统转向链上内容版本管理。用户可以通过ENS名称访问Dapp，ENS名称中包含的是该应用界面的IPFS哈希。在这种情况下，界面的更新需要通过多签或DAO发起链上交易。钱包可以在用户与Dapp交互时显示他们是否正在使用更安全的链上界面，或是较不安全的Web2界面。此外，钱包还可以显示当前交互的链的安全性（例如，是否已经通过多个安全审计）。

对于注重隐私的用户，钱包可以增加一个“偏执模式”，要求用户在进行HTTP请求和Web3操作前逐项点击确认，以增加安全性。

更先进的方式将是超越HTML和JavaScript，将Dapp的业务逻辑编写成专用语言，也许是在Solidity或Vyper上的一个轻量级覆盖层。浏览器可以根据需要自动生成任何功能所需的用户界面。 OKContract 就是一个已在实施这一思路的例子。

另一个方向是加密经济学信息防御：Dapp开发者、安全公司、链部署者等可以提供一个保证金，如果Dapp被黑客攻击或以某种方式误导用户，且这些行为经链上仲裁DAO确定，保证金将支付给受影响的用户。钱包可以根据保证金的大小向用户展示一个得分，用以反映Dapp的安全保障级别。

未来的长期展望

上述内容都基于传统的用户界面设计，这种界面涉及到用户点击操作和输入文本。然而，我们正处在更深刻变革的前沿：

• 人工智能（AI）：这可能会使我们从传统的“点击与输入”的交互方式转向一种新的方式：用户只需要说出自己的需求，AI便能理解并执行，甚至会自动完成任务。用户无需明确指定如何操作，AI会根据指令进行处理。
• 脑机接口（BCI）：包括眼动追踪等温和的技术，以及更直接甚至侵入式的技术（例如，Neuralink）。这些技术的进步可能会彻底改变我们与设备之间的交互方式，使得人类不再依赖传统的鼠标和键盘输入。
• 主动防御客户端：类似Brave浏览器能够主动保护用户免受广告、追踪器和其他不良对象的干扰，许多浏览器、插件和加密钱包都有专门的团队来保障用户免受各种安全和隐私威胁。这类“主动保护”技术将在未来十年变得更加强大。

这三种趋势将一起促使我们对用户界面进行更深层次的重新思考。通过自然语言输入、眼动追踪，或者最终通过更直接的脑机接口技术，再结合对用户历史的了解（例如包括短信内容，只要所有数据都在本地处理），“钱包”便能清晰地理解用户的需求。AI随后会将这种直觉转化为具体的“行动计划”：一系列链上和链下的操作，帮助用户完成目标。这将大大减少对第三方用户界面的依赖。如果用户需要与第三方应用或其他用户交互，AI应当为用户提供对抗性分析，识别潜在威胁并建议应对策略。理想的情况是，存在一个由不同团队生产的、具有不同偏见和激励结构的AI生态系统。

虽然这些更为激进的想法今天仍处于技术的初步阶段，但它们无疑是未来的发展方向，因此值得我们开始积极探索。

免责声明：

1. 本文转载自【Vitalik】，如果对转载内容有异议，请联系 Gate Learn 团队处理。
2. 法律免责声明：本文仅代表作者个人观点，并不构成任何投资建议。
3. 本文翻译由 Gate Learn 团队完成，除特别注明外，禁止复制、分发或抄袭本文翻译内容。