Vitalik：以太坊须要完成L2、钱包和隐私的三个转型

原文标题：《 The Three Transitions 》

原文作者：Vitalik Buterin

原文编译：MarsBit，MK

当以太坊从一项年轻的实验性技术转变为一项成熟的技术堆栈，能够真正为普通用户带来开放、全球化和无需许可的体验时，这个堆栈需要经历三个主要的技术转变，大致上同时进行：

• L2 扩展转变 - 所有人都迁移到 rollups

• 钱包安全性转变 - 所有人都迁移到智能合约钱包

• 隐私转变 - 确保提供隐私保护的资金转移，并确保正在开发的所有其他工具（社交恢复、身份、声誉）都能保护隐私

这是生态系统转型的三角关系。你只能选择 3 个中的 3 个。

没有第一个，以太坊就会失败，因为每笔交易都需要花费 3.75 美元（如果我们有另一轮牛市，那么价格为 82.48 美元），并且每个面向大众市场的产品最终都会忘记链，并且对一切采取集中化的解决方案。

没有第二个，以太坊就会失败，因为用户不愿意存储他们的资金（和非金融资产），所有人都会转移到集中式交易所。

没有第三个，以太坊就会失败，因为所有交易（和 POAPs 等）都公开给任何人看，这对于许多用户来说是对隐私的过高牺牲，所有人都会转移到至少有一些隐藏数据的集中化解决方案。

以上述原因，这三次转变至关重要。但由于解决这些问题需要强烈的协调性，因此它们也是具有挑战性的。不仅需要改进协议的功能，有些情况下，我们与以太坊互动的方式需要进行相当基础的变化，需要应用和钱包进行深入的改变。

这三次转变将彻底改变用户和地址之间的关系

在 L2 扩展世界中，用户将存在于许多 L2 中。你是 ExampleDAO 的成员，它位于 Optimism 上吗？那么你在 Optimism 上就有一个账户！你在 ZkSync 的稳定币系统中持有 CDP 吗？那么你在 ZkSync 上就有一个账户！你曾经尝试过一些恰好位于 Kakarot 上的应用吗？那么你在 Kakarot 上就有一个账户！用户只有一个地址的日子将一去不复返。

我在四个地方有 ETH，根据我的 Brave Wallet 视图。是的，Arbitrum 和 Arbitrum Nova 是不同的。不用担心，随着时间的推移，这会变得更加复杂！

智能合约钱包增加了更多的复杂性，使得在 L1 和各种 L2 上拥有相同地址变得更加困难。如今，大多数用户正在使用外部拥有的账户，其地址实际上就是用于验证签名的公钥的哈希 - 所以在 L1 和 L2 之间没有任何变化。然而，对于智能合约钱包，保持一个地址变得更加困难。尽管已经做了大量的工作，试图使地址成为网络间等价的代码的哈希，尤其是 CREATE 2 和 ERC-2470 单例工厂，但是要完美实现这一点非常困难。一些 L2（例如 "type 4 ZK-EVMs"）并不完全等同于 EVM，通常使用 Solidity 或中间装配代替，从而阻止了哈希等价。即使你可以拥有哈希等价性，钱包通过密钥变化改变所有权的可能性也会产生其他的非直观后果。

隐私需要每个用户拥有更多的地址，甚至可能改变我们处理的地址类型。如果隐私地址提议得到广泛使用，每个用户不再只有几个地址，或者在每个 L2 上有一个地址，而可能在每个交易中都有一个地址。其他的隐私方案，甚至是现有的方案如 Tornado Cash，会以不同的方式改变资产的存储方式：许多用户的资金存储在同一个智能合约（因此在同一个地址）中。要向特定的用户发送资金，用户需要依赖隐私方案自己的内部地址系统。

如我们所见，这三次转变以不同的方式削弱了「一个用户 ~= 一个地址」的心理模型，并且其中一些效果反馈到执行转变的复杂性中。两个特别的复杂点是：

1. 如果你想付款给某人，你如何获得付款给他们的信息？

2. 如果用户在不同的链上不同的地方存储了许多资产，他们如何进行密钥更换和社交恢复？

三次转变与链上支付（和身份）有关

我在 Scroll 上有硬币，我想支付咖啡（如果「我」是字面意思，指的是我这篇文章的作者，那么「咖啡」当然是「绿茶」的换喻）。你正在卖我咖啡，但你只准备在 Taiko 上接收硬币。我该怎么办？

基本上有两种解决方案：

1. 接收钱包（可能是商家，也可能只是普通个人）努力支持每个 L2，并具有一些异步整合资金的自动功能。

2. 接收者提供他们的 L2 和他们的地址，发送者的钱包通过某种跨 L2 桥接系统自动将资金路由到目标 L2。

当然，这些解决方案可以组合：接收者提供他们愿意接受的 L2 列表，发送者的钱包计算支付，这可能涉及直接发送（如果他们幸运的话），或者通过跨 L2 桥接路径。

但这只是三次转变引入的关键挑战的一个例子：像支付某人这样的简单行为开始需要比只有一个 20 字节地址的信息更多。

智能合约钱包的转变幸运的是对地址系统的负担不大，但是在应用程序堆栈的其他部分仍然有一些需要解决的技术问题。钱包需要更新，以确保它们不仅仅是在交易中发送 21000 gas，而且更重要的是确保钱包的支付接收端不仅跟踪从 EOAs 的 ETH 转移，也跟踪由智能合约代码发送的 ETH。依赖于地址所有权不变的假设的应用（例如，禁止智能合约以强制版税的 NFT）将不得不找到其他方式来实现他们的目标。智能合约钱包也会使一些事情变得更容易 - 特别是，如果有人只接收非 ETH 的 ERC 20 代币，他们将能够使用 ERC-4337 付款人来用那个代币支付 gas 费。

另一方面，隐私再次提出了我们还没有真正解决的主要挑战。最初的 Tornado Cash 并没有引入这些问题，因为它不支持内部转账：用户只能存入系统并提取出来。一旦你可以进行内部转账，用户就需要使用隐私系统的内部地址方案。在实践中，用户的「支付信息」需要包含（i）某种「支出公钥」，即接收者可以用来花费的秘密的承诺，以及（ii）发送者发送只有接收者可以解密的加密信息的方式，以帮助接收者发现支付。

隐私地址协议依赖于一个元地址的概念，其工作方式是：元地址的一部分是发送者的支出密钥的一个盲化版本，另一部分是发送者的加密密钥（尽管最小的实现可以设置这两个键是相同的）。

这里的关键教训是，在一个注重隐私的生态系统中，用户将拥有支出公钥和加密公钥，用户的「支付信息」将必须包含这两种密钥。除了支付以外，还有其他一些好的理由来扩展这个方向。例如，如果我们想要基于以太坊的加密电子邮件，用户将需要公开提供某种形式的加密密钥。在「EOA 世界」中，我们可以重新使用账户密钥来实现这个目标，但在一个安全的智能合约钱包世界中，我们可能应该有更明确的功能来实现这个目标。这也将有助于使基于以太坊的身份更兼容于非以太坊的分散隐私生态系统，最突出的例子是 PGP 密钥。

三个转型和密钥恢复

在一个用户可能有多个地址的世界中，实现密钥更改和社交恢复的默认方式是让用户对每个地址单独进行恢复程序。这可以一键完成：钱包可以包含软件，以便在所有用户的地址上同时执行恢复程序。然而，即使有这样的用户体验简化，天真的多地址恢复也存在三个问题：

• 燃气费用的不切实际：这一点不言自明。

• 反事实地址：尚未发布其智能合约的地址（实际上，这意味着你还没有从该账户发送过资金的账户）。作为一个用户，你有可能无限数量的反事实地址：每个 L2 上都有一个或多个，包括还不存在的 L2，还有一个完全不同的无限反事实地址集合，源自隐秘地址方案。

• 隐私：如果用户故意有许多地址以避免将它们链接在一起，他们肯定不希望通过在同一时间或差不多的时间恢复它们来公开链接所有的地址！

解决这些问题是困难的。幸运的是，有一个相当优雅的解决方案，表现得相当好：一种将验证逻辑和资产持有分开的架构。

每个用户都有一个密钥库合约，存在于一个位置（可能是主网或特定的 L2）。然后用户在不同的 L2 上有地址，其中每个地址的验证逻辑都是指向密钥库合约的指针。从这些地址中花费将需要一个进入密钥库合约的证明，显示当前（或更实际的，最近的）支出公钥。

证明可以通过几种方式实现：

1. 直接在 L2 中读取只读的 L1 访问权限。可以修改 L2 以给予他们直接读取 L1 状态的方法。如果密钥库合约在 L1 上，这将意味着 L2 内的合约可以「免费」访问密钥库。

2. 默克尔分支。默克尔分支可以证明 L1 状态到 L2，或者 L2 状态到 L1，或者你可以结合这两者来证明一个 L2 的状态的部分给另一个 L2。默克尔证明的主要弱点是由于证明长度的高燃气费用：一个证明可能需要 5 kB，尽管由于 Verkle 树，这将在未来减少到小于 1 kB。

3. ZK-SNARKs。你可以通过使用默克尔分支的 ZK-SNARK 而不是分支本身来减少数据成本。可以构建链下聚合技术（例如，基于 EIP-4337 ），让一个单一的 ZK-SNARK 验证所有的跨链状态证明在一个块中。

4. KZG 承诺。L2 或者在其之上构建的方案，可以引入一个顺序寻址系统，允许在这个系统内部的状态证明只有 48 字节长。像 ZK-SNARKs 一样，一个多证明方案可以将所有这些证明合并为每个块的单个证明。

如果我们想避免每次交易都做一个证明，我们可以实现一个更轻量级的方案，只需要恢复时做一个跨 L2 的证明。从一个账户中花费将取决于一个支出密钥，其对应的公钥存储在该账户中，但恢复将需要一个事务，复制在密钥库中的当前支出公钥。在反事实地址中的资金即使你的旧密钥不安全也是安全的： 「激活」一个反事实地址，将其转变为一个工作合约将需要做一个跨 L2 的证明，复制当前的支出公钥。这个在 Safe 论坛上的主题描述了一个类似的架构可能是如何工作的。

为了给这样的方案增加隐私，我们只需要加密指针，然后在 ZK-SNARKs 中做所有的证明：

通过更多的工作（例如，以这个工作为起点），我们也可以剥离大部分 ZK-SNARKs 的复杂性，制作一个更简单的基于 KZG 的方案。

这些方案可能会变得复杂。不过，这些方案之间有许多潜在的协同效应。例如，「密钥库合约」的概念也可能是前一节提到的「地址」挑战的解决方案：如果我们希望用户拥有持久性地址，这些地址不会在用户更新密钥时发生变化，我们可以将隐秘的元地址、加密密钥和其他信息放入密钥库合约中，并使用密钥库合约的地址作为用户的「地址」。

许多二级基础设施需要更新

使用 ENS 是昂贵的。今天， 2023 年 6 月，情况还不算太糟：交易费用虽然高，但还是可以与 ENS 域名费用相比较的。注册 zuzalu.eth 花费我大约 $ 27 ，其中 $ 11 是交易费用。但是如果我们再有一个牛市，费用将会飙升。即使没有 ETH 价格上涨，燃气费返回到 200 gwei 将会把域名注册的交易费提高到 $ 104 。因此，如果我们希望人们真正使用 ENS，特别是像去中心化社交媒体这样的应用场景，用户要求几乎免费注册（ENS 域名费用不是问题，因为这些平台为他们的用户提供子域），我们需要 ENS 在 L2 上运行。

幸运的是，ENS 团队已经开始行动，ENS 在 L2 上实际上正在发生！ERC-3668 （也称为「CCIP 标准」），与 ENSIP-10 一起，提供了一种在任何 L2 上自动验证 ENS 子域的方法。CCIP 标准要求设置一个智能合约，描述了验证 L2 数据证明的方法，域名（例如，Optinames 使用 ecc.eth）可以被放在这样一个合约的控制下。一旦 CCIP 合约在 L1 上控制 ecc.eth，访问 some subdomain.ecc.eth 将自动涉及查找和验证证明（例如，默克尔分支）的 L2 状态，实际上存储该特定子域。

实际获取证明涉及访问存储在合约中的一系列 URL，这 admittedly 感觉像是中心化，尽管我会辩称它实际上并不是：它是一个 1-of-N 信任模型（无效的证明会被 CCIP 合约的回调函数中的验证逻辑捕获，只要有一个 URL 返回有效的证明，就没有问题）。这个 URL 列表可能包含数十个 URL。

ENS CCIP 的工作是一个成功的例子，应该被视为我们所需要的那种激进改革是可能的标志。但还需要做更多的应用层面的改革。一些例子包括：

许多 dapp 依赖用户提供链下签名。对于外部拥有的账户（EOA），这很简单。ERC-1271 为智能合约钱包提供了一个标准化的方法来实现这一点。然而，许多 dapp 仍然不支持 ERC-1271 ；他们需要支持。

那些使用「这是 EOA 吗？」来区分用户和合约的 Dapp（例如，为了防止转账或执行版税）将会破裂。一般来说，我建议不要试图找到一个纯技术的解决方案；弄清楚特定的加密控制权转让是否是有益权益转让的问题是一个困难的问题，可能无法在不借助一些链下社区驱动机制的情况下解决。最有可能的是，应用程序将不得不更少地依赖于阻止转移，更多地依赖于像 Harberger 税这样的技术。

钱包如何与支出和加密密钥互动将需要改进。目前，钱包通常使用确定性签名来生成应用特定的密钥：使用 EOA 的私钥对一个标准随机数（例如，应用程序名称的哈希）进行签名，生成一个不能在没有私钥的情况下生成的确定性值，所以从技术上讲是安全的。然而，这些技术对于钱包来说是「不透明的」，阻止了钱包实施用户界面级别的安全检查。在一个更成熟的生态系统中，签名、加密和相关功能需要更明确地由钱包处理。

轻客户端（例如 Helios）将不得不验证 L2，而不仅仅是 L1。今天，轻客户端专注于检查 L1 头部的有效性（使用轻客户端同步协议），以及验证源于 L1 头部的 L1 状态和交易的默克尔分支。明天，他们还需要验证源于 L1 中存储的状态根的 L2 状态的证明（这个更先进的版本实际上会查看 L2 的预确认）。

钱包需要保护资产和数据

现在，钱包的业务是保护资产。一切都存在链上，钱包需要保护的唯一东西就是当前保护这些资产的私钥。如果你更换了密钥，你可以在第二天安全地在互联网上发布你以前的私钥。然而，在一个零知识证明的世界里，情况已经不再是这样了：钱包不仅仅在保护认证凭证，它还在保护你的数据。

我们在 Zupass 看到了这样一个世界的第一个迹象，Zupass 是在 Zuzalu 使用的基于 ZK-SNARK 的身份系统。用户有一个私钥，他们用它来认证系统，可以用来做基本的证明，比如「证明我是一个 Zuzalu 的居民，但不透露是哪一个」。但是，Zupass 系统也开始有其他应用程序建立在上面，最著名的就是邮票（Zupass 的 POAPs 版本）。

我许多的 Zupass 邮票之一，证明我是 Team Cat 的骄傲成员。

邮票比 POAPs 提供的关键特性是，邮票是私有的：你在本地持有数据，只有当你想让他们拥有你的这些信息时，你才会向他们证明邮票（或邮票上的一些计算）。但这增加了风险：如果你失去了这些信息，你就失去了你的邮票。

当然，持有数据的问题可以归结为持有一个加密密钥的问题：第三方（甚至是链）可以持有数据的加密副本。这有一个方便的优点，即你采取的行动不会改变加密密钥，因此不需要与保持你的加密密钥安全的系统进行任何交互。但即使如此，如果你失去了你的加密密钥，你就失去了一切。反过来，如果有人看到了你的加密密钥，他们就能看到被那把密钥加密的所有东西。

Zupass 的事实上的解决方案是鼓励人们在多个设备上存储他们的密钥（例如，笔记本电脑和手机），因为他们同时失去所有设备的几率很小。我们可以更进一步，使用秘密共享来存储密钥，将密钥分割在多个守护者之间。

这种通过 MPC 进行的社交恢复对钱包来说并不是一个足够的解决方案，因为这意味着不仅当前的守护者，而且之前的守护者可能会串通起来盗走你的资产，这是一个无法接受的高风险。但是，泄露隐私通常比完全失去资产的风险要小，如果某人需要高度保护隐私的用例，他可以通过不备份那些需要保护隐私行动的关联密钥，来接受更高的损失风险。

为了避免用一个复杂的多种恢复路径系统压垮用户，支持社交恢复的钱包可能需要同时管理资产恢复和加密密钥恢复。

回到身份问题

这些变化的一个共同主题是，你在链上使用的代表「你」的加密标识符的「地址」概念必须进行彻底的改变。「如何与我交互的指示」不再仅仅是一个 ETH 地址；他们必须以某种形式，包含在多个 L2 上的多个地址，隐秘的元地址，加密密钥和其他数据的某种组合。

实现这一点的一种方法是让 ENS 成为你的身份：你的 ENS 记录可以包含所有这些信息，如果你向某人发送 bob.eth（或 bob.ecc.eth，或...），他们可以查找并了解如何支付和与你互动的所有事情，包括在更复杂的跨领域和保护隐私的方式中。

但是，这种以 ENS 为中心的方法有两个弱点：

• 它将太多的事情与你的名字绑定。你的名字不是你，你的名字只是你的许多属性之一。你应该可以改变你的名字，而不需要移动你的整个身份配置文件并在许多应用中更新一大堆记录。

• 你不能有无信任的反事实名字。任何区块链的一个关键 UX 特性是能够向还没有与链交互过的人发送币。如果没有这样的功能，就会有一个鸡蛋和母鸡的问题：与链交互需要支付交易费用，而支付费用需要...已经拥有币。ETH 地址，包括带有 CREATE 2 的智能合约地址，都有这个特性。ENS 名称没有，因为如果两个 Bob 都在链下决定他们是 bob.ecc.eth，没有办法选择哪一个得到这个名字。

一种可能的解决方案是将更多的东西放入这篇文章前面架构中提到的密钥库合约中。密钥库合约可以包含关于你和如何与你互动的各种信息（通过 CCIP，其中一些信息可以在链下），用户可以将他们的密钥库合约作为主要的标识符。但他们接收的实际资产将被存储在各种不同的地方。密钥库合约不与名称绑定，它们是反事实友好的：你可以生成一个只能由拥有某些固定初始参数的密钥库合约初始化的地址。

另一个解决方案类别与放弃用户面向地址的概念有关，这与比特币支付协议的精神相似。一种想法是更多地依赖于发件人和收件人之间的直接通信渠道；例如，发件人可以发送一个索取链接（作为明确的 URL 或 QR 码），收件人可以使用该链接以他们希望的方式接受支付。

无论是发件人还是收件人首先采取行动，更多地依赖钱包直接实时生成最新的付款信息都可以减少摩擦。话虽如此，持久的标识符是方便的（尤其是与 ENS 一起），并且在实践中，发件人和收件人之间存在直接通信的假设是一个非常棘手的问题，所以我们可能会看到不同技术的组合。

在所有这些设计中，保持事物既去中心化又对用户易于理解至关重要。我们需要确保用户能够轻松地访问他们当前资产的最新视图，以及已发布的面向他们的信息。这些视图应该依赖开放的工具，而不是专有解决方案。避免更复杂的支付基础设施变成一个开发人员难以理解正在发生的事情并将其适应到新环境的不透明的「抽象塔」将需要努力工作。尽管面临挑战，但是实现以太坊的可扩展性、钱包安全性和普通用户的隐私至关重要。这不仅仅是关于技术可行性，而是关于普通用户的实际可访问性。我们需要迎接这个挑战。

特别感谢 Dan Finlay、Karl Floersch、David Hoffman 以及 Scroll 和 SoulWallet 团队的反馈、审查和建议。