Vitalik Buterin：以太坊的三次技术过渡

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

• L2 扩展过渡——每个人都转向 rollups
• 钱包安全过渡——每个人都转向智能合约钱包
• 隐私过渡——确保隐私保护资金转移可用，并确保所有其他正在开发的小工具（社会恢复、身份、声誉）都是隐私保护的

如果没有第一个，以太坊就会失败，因为每笔交易的成本为 3.75 美元（如果我们有另一次牛市，则为 82.48 美元），并且每个针对大众市场的产品都不可避免地会忘记链并为所有事情采用中心化的变通方法。

如果没有第二个，以太坊就会失败，因为用户不愿意存储他们的资金（和非金融资产），并且每个人都转向中心化交易所。

没有第三个，以太坊就会失败，因为所有交易（和 POAP 等）都公开供任何人查看，这对许多用户来说是一种太高的隐私牺牲，并且每个人都转向至少在某种程度上隐藏你的数据的中心化解决方案。

由于上述原因，这三个转变至关重要。 但它们也具有挑战性，因为要妥善解决这些问题需要密切协调。 需要改进的不仅仅是协议的功能； 在某些情况下，我们与以太坊交互的方式需要从根本上改变，需要对应用程序和钱包进行深刻的改变。

这三个过渡将从根本上重塑用户和地址之间的关系

在 L2 扩展世界中，用户将存在于许多 L2 上。 您是依赖 Optimism 的 ExampleDAO 的成员吗？ 那么您就有了一个 Optimism 的帐户！ 您是否在 ZkSync 上的稳定币系统中持有 CDP？ 那么你在 ZkSync 上就有了一个帐户！ 你有没有试过 kakarot 上的一些应用程序？ 那么您在 Kakarot 上就有了一个帐户！ 一个用户只有一个地址的日子将一去不复返了。

智能合约钱包增加了复杂性，使在 L1 和各种 L2 中拥有相同地址变得更加困难。 如今，大多数用户都在使用外部拥有的账户，其地址实际上是用于验证签名的公钥的哈希值——因此 L1 和 L2 之间没有任何变化。 然而，对于智能合约钱包，保留一个地址变得更加困难。 尽管已经做了很多工作来尝试使地址成为可以跨网络等效的代码哈希，最著名的是 CREATE2 和 ERC-2470 单例工厂，但很难使这项工作完美无缺。 一些 L2（例如“类型 4 ZK-EVM”）并不完全等同于 EVM，通常使用 Solidity 或中间程序集来代替，以防止哈希等效。 即使你可以拥有哈希等效，钱包通过密钥更改改变所有权的可能性也会产生其他不直观的后果。

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

正如我们所见，这三种过渡中的每一种都以不同的方式削弱了“一个用户~=一个地址”的心理模型，其中一些影响反馈到执行转变的复杂性中。 两个特殊的复杂点是：

如果您想付钱给某人，您将如何获得有关如何付钱给他们的信息？

如果用户有很多资产跨链存储在不同的地方，他们如何进行密钥更改和社交恢复？

三个过渡和链上支付（和身份）

我在Scroll上有币，我想花钱买咖啡（如果“我”是字面意思，指的是本文作者我，那么“咖啡”当然是“绿茶”的转喻）。 你在卖咖啡给我，但你只能在 Taiko 上接收币。 要做什么？

基本上有两种解决方案：

• 接收钱包（可以是商家，也可以是普通个人）非常努力地支持每个 L2，并具有一些用于异步整合资金的自动化功能。
• 收款人提供他们的 L2 和他们的地址，发件人的钱包通过一些跨 L2 桥接系统自动将资金路由到目的地 L2。

当然，这些解决方案可以结合使用：收件人提供他们愿意接受的 L2 列表，发件人的钱包计算出付款，如果他们幸运的话，这可能涉及直接发送，或者跨 L2 桥接路径。

但这只是这三个过渡带来的关键挑战的一个例子：像向某人付款这样的简单操作开始需要更多的信息，而不仅仅是一个 20 字节的地址。

幸运的是，向智能合约钱包的过渡不会对寻址系统造成太大负担，但应用程序堆栈的其他部分仍有一些技术问题需要解决。 钱包将需要更新以确保它们不会随着交易仅发送 21000 gas，并且确保钱包的付款接收端不仅跟踪来自 EOA 的 ETH 转账，而且还跟踪 ETH 更为重要 由智能合约代码发送。 依赖于地址所有权不可变假设的应用程序（例如，禁止智能合约以强制使用费的 NFT）将不得不寻找其他方法来实现其目标。 智能合约钱包也会让一些事情变得更容易——值得注意的是，如果某人只收到非 ETH ERC20 代币，他们将能够使用 ERC-4337 paymasters 使用该代币支付 gas。

另一方面，隐私再次构成了我们尚未真正应对的重大挑战。 最初的 Tornado Cash 没有引入任何这些问题，因为它不支持内部转账：用户只能存入系统并从系统中取出。 但是，一旦可以进行内部传输，用户将需要使用隐私系统的内部寻址方案。 在实践中，用户的“支付信息”需要包含（i）某种“消费公钥”，即对接收者可以用来消费的秘密的承诺，以及（ii）发送者发送加密货币的某种方式 只有收款人可以解密的信息，以帮助收款人发现付款。

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

这里的一个关键教训是，在隐私友好的生态系统中，用户将同时拥有消费公钥和加密公钥，并且用户的“支付信息”必须包括这两个密钥。 除了支付之外，还有充分的理由朝这个方向扩张。 例如，如果我们想要基于以太坊的加密电子邮件，用户将需要公开提供某种加密密钥。 在“EOA 世界”中，我们可以为此重复使用帐户密钥，但在安全的智能合约钱包世界中，我们可能应该为此提供更明确的功能。 这也有助于使基于以太坊的身份与非以太坊去中心化隐私生态系统更加兼容，尤其是 PGP 密钥。

三个过渡和密钥恢复

在每个用户有多个地址的世界中实现关键更改和社会恢复的默认方法是简单地让用户分别在每个地址上运行恢复过程。 这可以一键完成：钱包可以包含软件，可以同时对用户的所有地址执行恢复程序。 然而，即使有了这样的用户体验简化，简单的多地址恢复也存在三个问题：

Gas 成本不切实际：这个是不言自明的。

反事实地址：智能合约尚未发布的地址（实际上，这意味着您尚未从中发送资金的帐户）。 作为用户，您可能拥有无限数量的反事实地址：每个 L2 上都有一个或多个地址，包括尚不存在的 L2，以及由隐形地址方案产生的另一组无限反事实地址。

隐私：如果用户有意拥有多个地址以避免将它们相互链接，他们当然不希望通过同时或大约同时恢复它们来公开链接所有地址！

解决这些问题很难。 幸运的是，有一个性能相当不错的优雅解决方案：将验证逻辑和资产持有分开的架构。

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

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

L2里面直接只读L1访问。 可以修改 L2 以使其能够直接读取 L1 状态。 如果密钥库合约在 L1 上，这意味着 L2 内的合约可以“免费”访问密钥库

默克尔分支。 Merkle 分支可以将 L1 状态证明到 L2，或将 L2 状态证明到 L1，或者您可以将两者结合起来以将一个 L2 的部分状态证明到另一个 L2。 Merkle 证明的主要弱点是由于证明长度导致的高 gas 成本：一个证明可能需要 5 kB，但由于 Verkle 树，这将在未来减少到 < 1 kB。

ZK-SNARKs。 您可以通过使用 Merkle 分支的 ZK-SNARK 而不是分支本身来降低数据成本。 可以构建链下聚合技术（例如，在 EIP-4337 之上）让一个 ZK-SNARK 验证一个区块中的所有跨链状态证明。

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

如果我们想避免为每笔交易制作一个证明，我们可以实施一个更轻的方案，只需要一个跨 L2 证明来恢复。 从一个帐户中支出将取决于一个支出密钥，其相应的公钥存储在该帐户中，但恢复将需要一个事务来复制密钥库中的当前支出公钥。 即使您的旧密钥不安全，反事实地址中的资金也是安全的：“激活”反事实地址以将其转变为工作合约需要进行交叉 L2 证明以复制当前的 spending_pubkey。 Safe 论坛上的这个帖子描述了类似架构的工作原理。

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

随着更多的工作（例如，以这项工作为起点），我们还可以去除 ZK-SNARK 的大部分复杂性，并制作一个更简单的基于 KZG 的方案。

这些方案可能会变得复杂。 从好的方面来说，它们之间有许多潜在的协同作用。 例如，“keystore contracts”的概念也可以解决上一节中提到的“地址”挑战：如果我们希望用户拥有永久地址，不会在用户每次更新密钥时都改变，我们 可以将隐蔽的元地址、加密密钥等信息放入密钥库合约中，并将密钥库合约的地址作为用户的“地址”。

许多二级基础设施需要升级

使用 ENS 很昂贵。 今天，即 2023 年 6 月，情况还算不错：交易费用很高，但仍可与 ENS 域名费用相媲美。 注册 zuzalu.eth 花了我大约 27 美元，其中 11 美元是交易费。 但如果我们有另一个牛市，费用将会飙升。 即使没有 ETH 价格上涨，gas 费用回到 200 gwei 也会将域名注册的 tx 费用提高到 104 美元。 因此，如果我们希望人们实际使用 ENS，特别是对于用户要求几乎免费注册的去中心化社交媒体等用例（并且 ENS 域费用不是问题，因为这些平台为其用户提供子域），我们需要 ENS 在 L2 上工作。

幸运的是，ENS 团队站出来了，ENS on L2 正在发生！ ERC-3668（又名“CCIP 标准”）与 ENSIP-10 一起，提供了一种让任何 L2 上的 ENS 子域自动可验证的方法。 CCIP 标准要求建立一个智能合约，描述一种验证 L2 数据证明的方法，并且可以将域（例如 Optinames 使用 ecc.eth）置于此类合约的控制之下。 一旦 CCIP 合约控制了 L1 上的 ecc.eth，访问某些 subdomain.ecc.eth 将自动涉及查找和验证 L2 中实际存储该特定子域的状态证明（例如 Merkle 分支）。

实际上获取证明涉及到存储在合约中的 URL 列表，这诚然感觉像中心化，但我认为它实际上不是：它是一个 1-of-N 信任模型（无效的证明被验证逻辑捕获 在 CCIP 合约的回调函数中，只要其中一个 URL 返回有效证明，就可以了）。 URL 列表可能包含数十个。

ENS CCIP 的努力是一个成功的故事，它应该被视为一个标志，表明我们需要的那种激进改革实际上是可能的。 但是还有很多应用层改革需要完成。 几个例子：

许多 dapp 依赖于用户提供链下签名。 使用外部拥有账户 (EOA)，这很容易。 ERC-1271 为智能合约钱包提供了一种标准化的方式来做到这一点。 但是，很多 dapp 仍然不支持 ERC-1271； 他们将需要。

使用“这是 EOA 吗？”的 Dapps 区分用户和合同（例如，防止转让或强制使用费）将会破裂。 总的来说，我建议不要在这里寻找纯技术解决方案； 弄清楚特定的密码控制转移是否是受益所有权的转移是一个难题，如果不解决一些链下社区驱动的机制，可能无法解决。 最有可能的是，应用程序将不得不减少对防止转移的依赖，而更多地依赖哈伯格税等技术。

必须改进钱包与支出和加密密钥的交互方式。 目前，钱包通常使用确定性签名来生成特定于应用程序的密钥：使用 EOA 的私钥签署标准随机数（例如应用程序名称的哈希值）会生成一个没有私钥无法生成的确定性值，因此它是安全的 在纯技术意义上。 然而，这些技术对钱包来说是“不透明的”，阻止了钱包实现用户界面级别的安全检查。 在更成熟的生态系统中，签名、加密和相关功能将必须由钱包更明确地处理。

轻客户端（例如 Helios）将必须验证 L2 而不仅仅是 L1。 今天，轻客户端专注于检查 L1 header 的有效性（使用轻客户端同步协议），并验证 L1 状态的 Merkle 分支和植根于 L1 header的交易。 明天，他们还需要验证 L2 状态的证明，该证明植根于 L1 中存储的状态根（更高级的版本实际上会查看 L2 预确认）。

钱包将需要保护资产和数据

今天，钱包从事保护资产的业务。 一切都在链上，钱包唯一需要保护的是当前保护这些资产的私钥。 如果您更改密钥，您可以在第二天安全地在互联网上发布您以前的私钥。 然而，在 ZK 世界中，这不再是事实：钱包不仅保护身份验证凭证，它还保存着你的数据。

我们通过 Zupass 看到了这样一个世界的最初迹象，Zupass 是 Zuzalu 使用的基于 ZK-SNARK 的身份系统。 用户有一个用于向系统进行身份验证的私钥，可以用来制作基本证明，例如“证明我是 Zuzalu 居民，但无需透露是哪一个”。 但 Zupass 系统也开始在其上构建其他应用程序，最著名的是邮票(stamp）（Zupass 的 POAP 版本）。

与 POAP 相比，stamp 提供的关键特性是 stamp 是私有的：您在本地保存数据，如果您希望某人拥有关于您的信息，您只需向某人证明一个 stamp（或对 stamp 的一些计算）。 但这会增加风险：如果您丢失了该信息，您就会丢失邮票。

当然，持有数据的问题可以简化为持有单个加密密钥的问题：某些第三方（甚至链）可以持有数据的加密副本。 这有一个方便的优点，即您采取的操作不会更改加密密钥，因此不需要与保存您的加密密钥安全的系统进行任何交互。 但即便如此，如果您丢失了加密密钥，您将失去一切。 另一方面，如果有人看到您的加密密钥，他们就会看到用该密钥加密的所有内容。

Zupass 的实际解决方案是鼓励人们将密钥存储在多个设备（例如笔记本电脑和手机）上，因为他们同时无法访问所有设备的可能性很小。 我们可以更进一步，使用秘密共享来存储密钥，在多个监护人之间分配。

这种通过 MPC 进行的社会恢复对于钱包来说并不是一个充分的解决方案，因为这意味着不仅当前的监护人而且以前的监护人都可能串通窃取你的资产，这是一个不可接受的高风险。 但是隐私泄露的风险通常低于总资产损失风险，并且具有高隐私要求用例的人总是可以通过不备份与这些隐私要求高的操作相关的密钥来接受更高的丢失风险。

为了避免用户被多条恢复路径的拜占庭系统淹没，支持社交恢复的钱包可能需要同时管理资产恢复和加密密钥恢复。

回到身份

这些变化的共同点之一是“地址”的概念，即您用来在链上代表“您”的加密标识符，必须从根本上改变。 “如何与我互动的说明”将不再只是一个 ETH 地址； 它们必须以某种形式是多个 L2 上的多个地址、隐形元地址、加密密钥和其他数据的某种组合。

一种方法是让 ENS 成为你的身份：你的 ENS 记录可以只包含所有这些信息，如果你发送某人 bob.eth（或 bob.ecc.eth，或……），他们可以查找并 查看有关如何付款和与您互动的所有信息，包括更复杂的跨域和隐私保护方式。

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

它把太多的东西和你的域名联系在一起。 你的域名不是你，你的域名是你的许多属性之一。 应该可以更改您的域名，而无需移动您的整个身份资料并更新许多应用程序中的一大堆记录。

你不能有不受信任的反事实玉米。 任何区块链的一个关键 UX 功能是能够将币发送给尚未与链交互的人。 如果没有这样的功能，就会有一个 catch- 22：与链交互需要支付交易费用，这需要……已经有币。 ETH 地址，包括带有 CREATE2 的智能合约地址，都具有此功能。 ENS 域名不会，因为如果两个 Bob 都决定在链下他们是bob.ecc.eth，无法选择其中哪一个获得域名。

一种可能的解决方案是将更多内容放入本文前面架构中提到的密钥库合约中。 密钥库合约可以包含关于你的所有各种信息以及如何与你交互（对于 CCIP，其中一些信息可能是链下的），用户将使用他们的密钥库合约作为他们的主要标识符。 但是他们收到的实际资产将存储在各种不同的地方。 密钥库合约与名称无关，并且它们是反事实友好的：您可以生成一个地址，该地址可以证明只能由具有某些固定初始参数的密钥库合约初始化。

另一类解决方案与比特币支付协议类似，完全放弃面向用户地址的概念。 一种想法是更多地依赖发件人和收件人之间的直接沟通渠道； 例如，发件人可以发送一个索赔链接（作为明确的 URL 或 QR 码），收件人可以使用该链接按照他们的意愿接受付款。

不管是发送者还是接收者先行动，更多地依赖钱包直接实时生成最新的支付信息可以减少摩擦。 也就是说，持久标识符很方便（尤其是使用 ENS），而发送者和接收者之间直接通信的假设在实践中是一个非常棘手的假设，因此我们最终可能会看到不同技术的组合。

在所有这些设计中，让事物既分散又易于用户理解是最重要的。 我们需要确保用户可以轻松访问最新视图，了解他们当前的资产是什么，以及为他们发布了哪些消息。 这些观点应该依赖于开放工具，而不是专有解决方案。 要避免更加复杂的支付基础设施变成一个不透明的“抽象塔”，开发人员很难理解正在发生的事情并使其适应新的环境，这需要付出艰苦的努力。 尽管面临挑战，但为普通用户实现可扩展性、钱包安全和隐私对于以太坊的未来至关重要。 这不仅关乎技术可行性，还关乎普通用户的实际可访问性。 我们需要挺身而出迎接这一挑战。