Vitalik：以太坊要大众采用仍需三个转变

• 原文链接： https://vitalik.eth.limo/general/2023/06/09/three_transitions.html
• 译文出自：登链翻译计划
• 译者：翻译小组 校对：Tiny 熊
• 本文永久链接：learnblockchain.cn/article…

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

1. L2 扩容转变 - 所有人都迁移到 rollups
2. 钱包安全性转变 - 所有人都迁移到智能合约钱包
3. 隐私转变 - 确保提供隐私保护的资金转移，并确保正在开发的所有其他工具（社交恢复、身份、声誉）都能保护隐私

生态系统转变三角， 缺一不可

没有第一个 L2 扩容转变，以太坊会失败，因为每笔交易都需要花费3.75美元（如果我们有另一轮牛市，费用为82.48美元），而每一个以大众市场为目标的产品都不可避免地遗忘链，并采用中心化的工作方法来处理一切。

没有第二个（钱包安全性转变），以太坊会失败，因为用户不愿意存储他们的资金（和非金融资产），所有人都会转移到中心化交易所。

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

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

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

在一个二层网络的世界里，用户将存在于很多二层网络上。你是ExampleDAO 的成员么， 它在 Optimism 上，那么你在 Optimism 上就有一个账户! 你是否在ZkSync上的稳定币系统中持有CDP？那你就有一个ZkSync上的账户!你是否曾经去尝试过一些碰巧在 Kakarot 网络上的应用？那么你在 Kakarot 上就有账户， 一个用户只有一个地址的日子将不复存在。

根据 Brave Wallet 的显示，我在四个地方有ETH。而且是的，Arbitrum 和 Arbitrum Nova 是不同的。别担心，随着时间的推移，会越来越混乱的！。

智能合约钱包增加了更多的复杂性，因为它使得在L1和各种L2之间拥有相同的地址变得更加困难。今天，大多数用户都在使用外部拥有的账户，这个账户地址实际上是用于验证签名的公钥的哈希值--因此在L1和L2之间没有任何不同。然而，有了智能合约钱包，保持一个地址变得更加困难。

虽然已经做了很多工作试图使地址成为可以跨网络的等价的代码哈希，最明显的是CREATE2和ERC-2470 singleton factory，但很难使其完美运作。一些L2（例如"类型4 ZK-EVMs"）并不是完全的EVM等价，通常使用替代的 Solidity 或中间汇编，从而阻止了哈希等价。即使可以有哈希等价，钱包通过密钥变更改变所有权的可能性也会产生其他不直观的后果。

隐私要求每个用户都有甚至更多的地址，甚至可能改变我们使用的哪种的地址。如果隐身地址的建议被广泛使用，而不是每个用户只有几个地址，或每个L2有一个地址，而是用户可能每个交易都有个地址。其他隐私方案，甚至现有的方案，如 Tornado Cash，以不同的方式改变资产的存储方式：许多用户的资金被存储在同一个智能合约中（因此在同一个地址中）。要向特定的用户发送资金，用户将需要依靠隐私方案自己的内部地址系统。

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

1. 如果你想付款给某人，你将如何获得“如何付款给他们” 这个信息呢？
2. 如果用户有许多资产存储在不同链的不同地方，他们如何做密钥变更和社会恢复？

三个转变和链上支付（和身份）的问题

我在 Scroll 网络上有币，我想支付咖啡。你把咖啡卖给我，但你只支持在 Taiko 网络上接收币。我该怎么办？

基本上有两个解决方案：

1. 接收钱包（可能是商家，但也可能只是普通个人）非常努力地支持每一个 L2，并有一些自动功能，以异步方式整合资金。
2. 接收者提供他们所支持的L2和他们的地址，而发送者的钱包通过一些跨 L2 的桥接系统自动将资金发送到目的地L2。

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

但这只是这三个转变所带来的关键挑战的一个例子：简单的支付行为，却开始需要更多的信息，而不仅仅是一个20字节的地址。

幸运的是，向智能合约钱包的过渡并没有给寻址系统带来很大的负担，但在应用栈的其他部分仍有一些技术问题需要解决。钱包将需要更新，以确保它们不会给交易只限定21000个Gas，而且更重要的是要确保支付接收方不仅跟踪来自EOA的ETH转账，还要跟踪智能合约代码发送的ETH。依靠地址所有权是不可改变的假设的应用（例如，禁止智能合约执行版税的NFT)将不得不找到其他方法来实现他们的目标。智能合约钱包也将使一些事情变得*容易--特别是，如果有人只收到了非ETH的ERC20代币，他们将能够使用ERC-4337 paymasters用该代币支付Gas。

另一方面，隐私问题再次带来了重大挑战，我们还没有真正处理好。最初的 Tornado Cash 并没有引入任何这些问题，因为它不支持内部转账：用户只能向系统中存款，并从系统中提款。然而，一旦你可以进行内部转账，用户将需要使用隐私系统的内部寻址方案。在实践中，用户的 "支付信息 "将需要同时包含(i)某种 "支出公钥"，既接收者可以用来支出的秘密的承诺，以及(ii)发送者发送只有接收者可以解密的加密信息的某种方式，以帮助接收者发现支付。

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

基于加密和ZK-SNARKs的抽象隐形地址方案的示意图。

这里的一个关键教训是，在一个对隐私友好的生态系统中，用户将同时拥有支出公钥和加密公钥，而用户的 "支付信息" 将必须包括这两个密钥。除了支付之外，也有很好的理由向这个方向扩容。例如，如果我们想要基于以太坊的加密电子邮件，用户将需要公开提供某种加密密钥。在 "EOA世界 "中，我们可以重用账户密钥来实现，但在一个安全的智能合约-钱包世界中，我们可能应该有更明确的功能来实现它。这也将有助于使基于以太坊的身份与非以太坊去中心化的隐私生态系统更加兼容，最明显的例子是PGP密钥。

三个转变和密钥恢复

在每个用户有很多地址的情况下，实现密钥变更和社会恢复的默认方式是简单地让用户在每个地址上分别运行恢复程序。这可以一键完成：钱包可以包含软件，在用户的所有地址同时执行恢复程序。然而，即使有这样的用户体验简化，天真的多地址恢复也有三个问题：

1. Gas 成本不切实际：这个问题是不言而喻的。
2. 反事实地址：尚未部署智能合约的地址（在实践中，这将意味着你还没有发送资金的账户）。你作为一个用户，可能有无限多的反事实地址：每个L2上都有一个或多个，包括尚未存在的L2，以及由隐形地址计划产生的一整套其他无限的反事实地址。
3. 隐私：如果一个用户故意拥有许多地址，以避免它们之间的联系，他们肯定不想通过在同一时间或前后恢复它们来公开联系所有的地址！

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

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

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

• 在L2 只读访问 L1： 可以修改 L2，让它们有办法直接读取L1状态。如果keystore合约在L1上，这将意味着 L2 上的合约可以 "免费" 访问keystore

• Merkle 树分支：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，还是建立在L2之上的方案，都可以引入一个顺序寻址系统，允许这个系统内的状态证明只有48字节长。像ZK-SNARKs一样，一个多重证明方案可以将所有这些证明合并为每个区块的一个证明。

如果我们想避免每笔交易进行一次证明，可以实现一个更轻的方案，只需要一个跨L2证明来恢复。从一个账户的支出将依赖一个支出密钥，其对应的pubkey存储在该账户中，但恢复将需要一个交易来复制 Keystore 中当前的spending_pubkey。反事实地址中的资金是安全的，即使你的旧Key不安全：激活 一个反事实的地址，把它变成一个可用合约，需要做一个跨L2证明，复制到当前的spending_pubkey。Safe 论坛上的这个主题描述了一个类似的架构如何工作。

要在这样的方案中添加隐私特性，那么我们只需对指向进行加密，并在ZK-SNARKs内进行所有的证明：

通过更多的工作（例如，使用这项工作作为起点），我们也可以剥去ZK-SNARKs的大部分复杂性，做出一个更原始的基于KZG的方案。

这些方案会变得很复杂。但它们之间有许多潜在的协同效应。例如，"Keystore 合约" 的概念也可以成为上一节提到的 "地址" 挑战的解决方案：如果我们希望用户有持久的地址，该地址在不会在用户每次更新 Key 时发生改变，我们可以把隐形元地址、加密Key 和其他信息放入Keystore 合约，并把Keystore 合约的地址作为用户的 "地址"。

大量的二级基础设施需要更新

使用 ENS 是很昂贵的。在 2023 年 6 月的今天，情况还不算太糟：交易手续费仍很可观，与ENS域名费相比仍占相当比例。注册 zuzalu.eth域名大概花了我27美元，其中11美元是交易费。但是，如果我们有另一个牛市，费用将暴涨。即使没有ETH价格上涨，Gas 费恢复到 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，访问一些subdomain.ecc.eth将自动寻找和验证L2中实际存储该特定子域名的状态的证明（例如Merkle树分支）。

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

ENS CCIP 的努力应该被看作是一个迹象，表明我们所需要的那种彻底的改革实际上是可能的。但还需要做更多的应用层面的改变， 举几个例子：

• 很多dapp都依赖于用户提供链外的签名。通过外部拥有的账户（EOAs），这很容易。ERC-1271为智能合约钱包提供了一种标准化的方式。然而，很多dapp仍然不支持ERC-1271；需要 应用层做出改变来支持。
• 使用 "这是EOA地址吗？" 来区分用户和合约（例如，禁止转移或强制收取版税）的dapp将会崩溃。一般来说，我建议不要试图在这里找到一个纯技术解决方案；弄清楚一个特定的控制权的转移是否有益的是一个困难的问题，如果不依靠一些链外社区驱动机制，可能就无法解决。最有可能的是，应用将不得不减少对禁止转移的依赖，而更多地依赖像Harberger税这样的技术。
• 钱包处理支出和加密密钥（encryption keys）的方式将必须改进。目前，钱包通常使用确定性签名来生成特定于应用程序的密钥：用EOA的私钥签署一个标准的随机数（例如，应用程序名称的哈希值），产生一个确定性的值，没有私钥就无法生成，因此从纯技术的角度来看是安全的。然而，这些技术对钱包来说是 "不透明的"，使钱包无法实现用户界面级别的安全检查。在一个更成熟的生态系统中，签名、加密和相关功能将不得不由钱包更明确地处理。
• 轻型客户端（例如Helios）将不得不验证L2，而不仅仅是L1。今天，轻型客户端侧重于检查L1 区块头的有效性（使用轻型客户端同步协议），并验证L1状态的 Merkle 树分支和在 L1 区块头的交易。明天，他们还需要验证存储在L1中的状态根的 L2 状态根的证明（更高级的版本实际上会查看 L2 预确认）。

钱包将需要确保资产和数据的安全

今天，钱包的业务是确保资产的安全。由于一切都在链上，目前钱包需要保护的唯一东西是守护这些资产的私钥。如果你改变了密钥，你可以在第二天安全地在互联网上公布你以前的私钥。然而，在ZK的世界里，这不再是真的：钱包不仅仅是保护认证凭证，它还持有你的数据。

我们通过 Zupass 看到了这样一个世界的最初迹象，Zupass 是在 Zuzalu 使用的基于ZK-SNARK的身份系统。用户有一个私钥，他们用它来做认证系统，它可以用来做基本的证明，比如 "证明我是Zuzalu的公民，但不透露是哪一个人"。然而，开始有其他应用程序建立 Zupass 系统之上，最明显例子的是stamps（印章）（Zupass的POAPs版本）。

我的许多 Zupass 印章之一，证实了我是猫咪团队的骄傲成员。

与POAP相比，印章的主要特点是印章是私有的：你在本地持有数据，如果你想让别人知道你的信息，你只能向他们证明一个印章（或印章上的一些计算）。但这创造了额外的风险：如果你失去了这些信息，你就失去了你的印章。

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

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

这种通过MPC的社会恢复对于钱包来说不是一个足够好的解决方案，因为它意味着不但当前的监护人，而且以前的监护人也可能串通起来偷窃你的资产，这是一个不可接受的高风险。但是，隐私泄露的风险通常总是比资产损失要低，有高隐私要求的使用场景的人总是可以接受较高的损失风险，他可以不备份与这些有隐私要求的行为相关的密钥。

为了避免用户被多种恢复路径的繁琐系统所困扰，支持社会恢复的钱包可能需要同时管理资产的恢复和加密密钥的恢复。

回到身份话题

这些变化的一个共同点是，"地址"的概念，即你用来代表链上 "你"的加密标识符，将不得不彻底改变。"指示如何与我交互" 将不再仅仅是一个ETH地址；它们将不得不以某种形式，成为多个L2上的多个地址、隐形元地址、加密密钥和其他数据的某种组合。

一种方法是让ENS成为你的身份：你的ENS记录可以包含所有这些信息，如果你向别人发送bob.eth（或bob.ecc.eth，或...），他们可以查询并看到关于如何给你支付和如何与你交互的一切，包括以更复杂的跨域和隐私保护的方式。

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

• 它把太多的东西与你的名称联系在一起。你的名称不是你，你的名称是你的许多属性中的一个。应该可以改变你的名称，而不需要移动你的所有身份资料并在许多应用程序中更新一大堆记录。
• 你不能有无信任的反事实的名称。任何区块链的一个关键用户体验是能够向尚未与链上的人交互的人发送币。如果没有这样的功能，就会有一个相互依赖陷阱：与链上交互（创建他的名称的账号）需要支付交易费用，这就需要他已经拥有Coin（可是他还没有名称的账号）。ETH地址，包括CREATE2的智能合约地址，都有这个功能。ENS名称则没有，因为如果两个Bob都在链外决定自己是bob.ecc.eth，就没有办法选择哪一个得到这个名称。

一个可能的解决方案是把更多的东西放到本文前面的架构中提到的keystore合约中。keystore合约可以包含所有关于你的各种信息，以及如何与你交互（通过CCIP，其中一些信息可以是链外的），而用户将使用他们的keystore合约作为他们的主要标识。但他们收到的实际资产将被存储在各种不同的地方。keystore 合约不与名称绑定，而且它们是反事实的：你可以生成一个地址，而这个地址可以证明它只能由具有某些固定初始参数的keystore合约初始化。

另一类解决方案与完全放弃面向用户的地址概念有关，与比特币支付协议的思想相似。一个想法是更多地依赖发送者和接收者之间的直接通信渠道；例如，发送者可以发送一个索取（claim）链接(作为一个明确的URL或QR码)，接收者可以用该链接来接受他们期望的付款。

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

在所有这些设计中，保持事情的去中心化和对用户的可理解性是最重要的。我们需要确保用户能够很容易地获得最新的信息，了解他们当前的资产是什么，以及有哪些信息是为他们发布的。这些观点应该依赖于开放的工具，而不是专有的解决方案。要避免更复杂的支付基础设施变成一个不透明的 "抽象塔"，让开发人员难以理解正在发生的事情并适应新的环境。尽管有这些挑战，但为普通用户实现可扩容性、钱包安全性和隐私性，对以太坊的未来至关重要。这不仅仅是技术上的可行性，而且是普通用户的实际可及性。我们需要起来迎接这个挑战。

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

本翻译由 DeCert.me 协助支持， DeCert.me 希望每一位开发者能拥有自己的可信技能履历。