Vitalik：以太坊生态系统需要三个技术转型

随着以太坊从一项年轻的实验性技术发展成为能够为普通用户带来开放、全球和无需许可体验的成熟技术堆栈，有三个主要的技术转型需要同时进行：

第一是L2扩容转型——所有人都转向Rollup技术；

第二是钱包安全转型——所有人都开始使用智能合约钱包；

第三是隐私转型——确保提供保护隐私的资金转账功能，并确保正在开发的所有其他工具（社交恢复、身份认证、声誉等）都具备隐私保护的特性。

以太坊生态系统转型三角。你只能选择全部三个。

没有第一项，以太坊将失败，因为每笔交易的成本为3.75美元（如果我们再次经历牛市，成本将达到82.48美元），而每个面向大众市场的产品都不可避免地会放弃链上的交易并采用中心化的解决方案。

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

没有第三项，以太坊将失败，因为对于许多用户来说，所有交易（以及POAP等）都公开可见，这对隐私的牺牲太大了，所有人都会转向至少在某种程度上隐藏数据的中心化解决方案。

基于上述原因，这三个转型至关重要。但是由于涉及到的协调工作非常复杂，因此它们也具有挑战性。需要改进的不仅仅是协议的功能；在某些情况下，我们与以太坊的交互方式需要从根本上进行深刻的改变，这需要应用程序和钱包进行重大变革。

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

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

我的Brave钱包视图，我在四个地方都持有以太坊。是的，Arbitrum和Arbitrum Nova是不同的。别担心，随着时间的推移，情况会变得更加复杂！

智能合约钱包增加了更多的复杂性，因为它使得在L1和各种L2网络上拥有相同的地址变得更加困难。如今，大多数用户使用的是外部拥有账户（externally owned accounts），其地址实际上是用于验证签名的公钥的哈希值——因此，在L1和L2之间没有任何变化。然而，使用智能合约钱包时，保持一个地址变得更加困难。尽管已经做了很多工作，尝试使地址成为可以在不同网络之间等效的代码哈希，其中最重要的是CREATE2和ERC-2470 singleton factory，但要完美地实现这一点很困难。一些L2网络（例如，“第四类ZK-EVM”）并不完全等效于EVM，通常使用的是Solidity或中间汇编语言，而不是哈希等效。即使可以实现哈希等效，钱包通过密钥更改而改变所有权的可能性会导致其他难以预测的后果。

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

正如我们所见，这三个转型以不同的方式削弱了“一个用户≈一个地址”的心理模型，其中一些效果反过来又增加了执行这些转型的复杂性。其中两个特别复杂的问题是：

1、如果你想支付某人，你将如何获取支付信息？

2、如果用户将资产存储在不同链上的不同位置，他们如何进行密钥更改和社交恢复？

这三个转型与链上支付（和身份）

我在Scroll上持有代币，我想用它们购买咖啡（如果这个字面的“我”指的是本文作者Vitalik，那么“咖啡”当然是指“绿茶”）。你在Taiko上销售咖啡，但你只接受Taiko上的代币。怎么办？

基本上有两种解决方案：

1、收款钱包（可以是商家，也可以是普通个人）努力支持每个L2，并具备一些异步资金合并功能。

2、收款人在地址旁提供他们的L2信息，发送方的钱包通过某种跨L2桥接系统自动将资金路由到目标L2。

当然，这些解决方案可以结合使用：收款人提供他们愿意接受的L2列表，发送方的钱包确定支付方式，可以直接发送（如果运气好的话），或者通过跨L2桥接路径进行支付。

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

幸运的是，转向智能合约钱包对于地址系统来说并不是一个很大的负担，但应用程序堆栈的其他部分仍然存在一些需要解决的技术问题。钱包需要更新，以确保它们在发送交易时不仅发送21000 gas，同时还需要更加重视确保钱包接收端不仅跟踪来自EOA的ETH转账，还要跟踪来自智能合约代码的ETH转账。依赖于地址所有权不可变的应用程序（例如，禁止智能合约以执行版税的NFT）将不得不找到其他实现目标的方式。智能合约钱包也会使某些事情变得更容易，尤其是如果某人只接收非ETH ERC20代币，他们将能够使用ERC-4337 paymaster来使用该代币支付gas费用。

另一方面，隐私问题再次成为我们尚未真正解决的重大挑战。最初的Tornado Cash没有引入这些问题，因为它不支持内部转账：用户只能向系统存款和提取款项。然而，一旦可以进行内部转账，用户将需要使用隐私系统的内部寻址方案。实际上，用户的“支付信息”将需要包含（i）某种“花费公钥”，即接收方可以用来支出的秘密承诺，以及（ii）发送方可以发送加密信息，只有接收方才能解密的帮助接收方发现支付的方式。

隐身地址（Stealth address）协议依赖于元地址（meta-address）的概念，其工作原理如下：元地址的一部分是发送方的经过蒙蔽的花费密钥，另一部分是发送方的加密密钥（尽管最简实现可以将这两个密钥设置为相同）。

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

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

这三个转型和秘钥恢复

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

1、Gas成本不切实际：这一点不言而喻。

2、虚拟地址（Counterfactual addresses）：尚未发布智能合约的地址（实际上，这将意味着你尚未从其发送资金的账户）。作为用户，你可能有无限多个虚拟地址：每个L2上都有一个或多个，包括尚不存在的L2，以及从隐身地址方案中产生的一整套无限虚拟地址。

3、隐私：如果用户有意使用多个地址以避免将它们互相关联，那么他们肯定不希望通过同时或接近同时恢复它们来公开关联所有这些地址！

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

每个用户都有一个keystore合约，它存在于一个位置（可以是主网或特定的L2）。然后，用户在不同的L2上拥有地址，每个地址的验证逻辑是指向keystore合约的指针。从这些地址支出资金将需要提供一个证明，证明资金的当前（或更现实地说，非常近期的）花费公钥。

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

直接在L2内部对L1进行只读访问。可以修改L2以使其能够直接读取L1状态。如果keystore合约在L1上，这意味着L2内的合约可以“免费”访问keystore。

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

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

KZG承诺。无论是L2还是建立在其之上的方案，都可以引入顺序编址系统，允许在该系统内部的状态证明仅为48字节。与ZK-SNARKs一样，多证明方案可以将所有这些证明合并为每个区块的单个证明。

如果我们想避免每个交易都需要一个证明，可以实施一种更轻量级的方案，仅需要跨L2证明进行恢复。从一个账户支出将依赖于一个花费密钥，其对应的公钥存储在该账户内部，但恢复将需要一个交易，将当前的花费公钥复制到keystore中。即使你的旧密钥不安全，虚拟地址中的资金也是安全的：将虚拟地址“激活”以将其转化为可用合约将需要进行跨L2证明，以复制当前的花费公钥。Safe论坛上的有主题描述了类似架构的工作方式。

要为这样的方案增加隐私性，我们只需对指针进行加密，并在ZK-SNARKs内部进行所有的证明：

通过进一步的工作（例如以此工作为起点），我们还可以剥离ZK-SNARKs的大部分复杂性，构建一个更简化的基于KZG的方案。

这些方案可能会变得复杂。好处是它们之间存在许多潜在的协同效应。例如，“keystore合约”的概念也可以是前一节提到的“地址”的解决方案：如果我们希望用户拥有持久的地址，不会在用户更新密钥时每次都更改，我们可以将隐身元地址、加密密钥和其他信息放入keystore合约，并将keystore合约的地址用作用户的“地址”。

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

使用ENS很昂贵。2023年6月的现在虽然没之前贵，但注册域名的交易费用仍然相对较高，与ENS域名费用相当。例如，注册zuzalu.eth大约花费了27美元，其中11美元是交易费用。但如果市场再次出现牛市，费用将飙升。即使ETH价格没有上涨，如果Gas费回到200 gwei，域名注册的交易费用将达到104美元。因此，如果我们希望人们真正使用ENS，特别是对于像去中心化社交媒体这样的用例，用户要求几乎免费注册（ENS域名费用并不是问题，因为这些平台可以为用户提供子域名），我们需要在Layer 2上使用ENS。

幸运的是，ENS团队已经迈出了步伐，ENS在Layer 2上正在实现！ERC-3668（也称为“CCIP标准”）和ENSIP-10提供了一种在任何Layer 2上自动验证ENS子域的方式。CCIP标准要求设置一个智能合约，描述在Layer 2上验证数据证明的方法，而一个域名（例如，Optinames使用ecc.eth）可以被放置在这样一个合约的控制下。一旦CCIP合约在L1上控制ecc.eth，访问某个subdomain.ecc.eth将自动查找和验证一个存储该特定子域的Layer 2状态的证明（例如，Merkle branch）。

实际获取这些证明涉及到访问存储在合约中的URL列表，尽管这在某种程度上可能看起来像是中心化，但我会说这实际上并不是：这是一种1对N的信任模型（无效的证明会被CCIP合约回调函数中的验证逻辑捕获，只要其中一个URL返回有效的证明，就可以了）。URL列表可能包含几十个URL。

ENS的CCIP努力是一个成功的案例，应该被视为我们需要的激进改革实际可行的标志。但还有很多应用层面的改革需要进行。以下是一些例子：

许多DApp依赖用户提供链下签名。对于外部账户（EOA），这很容易。ERC-1271提供了一种标准化的方法来为智能合约钱包执行此操作。然而，许多DApp仍然不支持ERC-1271，它们需要进行适配。

使用“is this an EOA? ”来区分用户和合约的DApp（例如，防止转账或强制执行版税）将会出现问题。一般来说，我建议不要试图在这里找到纯技术解决方案；确定特定的加密控制转移是否是有利益所有权转移是一个困难的问题，可能无法在没有借助一些链下社区驱动机制的情况下解决。最有可能的是，应用程序将更少地依赖于阻止转移的技术手段，而更多地依赖于类似Harberger税这样的技术。

钱包与支出和加密密钥的交互将需要改进。目前，钱包通常使用确定性签名生成应用程序特定的密钥：使用EOA的私钥对一个标准的nonce（例如应用程序名称的哈希）进行签名会生成一个确定的值，除非拥有私钥，否则无法生成该值，因此从纯技术角度来说是安全的。然而，这些技术对钱包来说是“不透明”的，阻止了钱包实现用户界面级别的安全检查。在一个更成熟的生态系统中，签名、加密和相关功能将需要由钱包更加明确地处理。

轻客户端（例如Helios）将需要验证Layer 2而不仅仅是Layer 1。目前，轻客户端专注于检查L1区块头信息的有效性（使用轻客户端同步协议），并验证基于L1区块头信息的L1状态和交易的Merkle branch。未来，它们还将需要验证以L1中存储的状态根为根的L2状态的证明（更高级的版本将实际查看L2预确认）。

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

目前，钱包的任务是保护资产。一切都存储在链上，钱包需要保护的只是当前保护这些资产的私钥。如果更换密钥，你可以安全地在第二天将之前的私钥公开发布在互联网上。然而，在零知识世界中，情况就不再如此：钱包不仅仅保护身份验证凭证，还保存着你的数据。

我们在Zuzalu使用基于ZK-SNARK的身份系统Zupass，看到了这样一个世界的最初迹象。用户有一个私钥，用于认证到系统中，可以用于生成基本证明，例如“证明我是Zuzalu居民，而不暴露是哪个居民”。Zupass系统还开始在其上构建其他应用程序，最重要的是stamps（Zupass版本的POAP）。

我许多Zupass邮票中的一个，确认我是Team Cat的成员。

stamps相对于POAP的关键特点是它们是隐私的：你在本地保存数据，只有当你希望将该信息提供给某人时，才会向其ZK证明一个stamps（或对stamps进行某些计算）。但这也带来了额外的风险：如果丢失了该信息，你将失去你的stamps。

当然，持有数据的问题可以简化为持有单个加密密钥的问题：第三方（甚至是链上）可以持有数据的加密副本。这具有方便的优势，即你采取的操作不会更改加密密钥，因此不需要与保存加密密钥的系统进行任何交互。但即使如此，如果你丢失了加密密钥，就会失去所有数据。而且，反过来，如果有人看到了你的加密密钥，他们就能够看到使用该密钥加密的所有内容。

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

通过MPC社交恢复并不是钱包的足够解决方案，因为这意味着不仅当前的保护者，而且之前的保护者也可能串通起来窃取你的资产，这是一个无法接受的高风险。但隐私泄露通常比完全丧失资产的风险更低，对于具有高隐私需求的用例，可以通过不备份与这些隐私需求相关的密钥来接受更高的丧失风险。

为了避免让用户陷入一个复杂的多重恢复路径系统中，支持社交恢复的钱包可能需要管理资产恢复和加密密钥恢复两个方面。

回到身份

这些变化中的一个共同主题是，作为区块链上的身份表示的"地址"的概念将需要发生根本性的变化。”如何与我互动的指令"将不再仅仅是一个ETH地址；它们将以某种形式，可能是多个L2上的多个地址、隐形元地址、加密密钥和其他数据的组合来表示。

其中一种方法是将ENS作为你的身份：你的ENS记录可以包含关于如何支付和与你互动的所有信息，如果你向某人发送bob.eth（或bob.ecc.eth等），他们可以查询并了解与你互动的一切，包括在更复杂的跨域名和隐私保护方式下。

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

它将太多的内容与你的姓名关联在一起。你的姓名并不代表你的全部，它只是你的众多属性之一。应该能够更改你的姓名，而无需迁移整个身份配置文件并更新许多应用程序中的记录。

你无法拥有无需信任的虚拟名字（counterfactual names）。任何区块链的一个关键用户体验功能是能够向尚未与链交互的人发送代币。如果没有这样的功能，就会陷入进退两难的境地：与链进行交互需要支付交易费用，而支付交易费用则需要......已经拥有代币。ETH地址，包括具有CREATE2的智能合约地址，具备这个功能。ENS名称则没有，因为如果两个Bob都在链下决定他们是bob.ecc.eth，就没有办法选择哪一个Bob能够获得这个名称。

一种可能的解决方案是将更多的内容放入之前在本文架构中提到的keystore合约中。keystore合约可以包含关于你和与你互动的各种信息（并且使用CCIP，其中一些信息可以是链下的），用户将使用其keystore合约作为其主要标识符。但是，他们实际收到的资产将存储在各种不同的地方。keystore合约与名称无关，并且对于虚拟名字友好：你可以生成一个地址，只能由具有特定固定初始参数的keystore合约进行初始化。

另一类解决方案涉及完全放弃用户面向的地址概念，类似于比特币的支付协议。一种想法是更多地依赖发送方和接收方之间的直接通信渠道；例如，发送方可以发送一个索取链接（作为显式URL或二维码），接收方可以使用该链接以任何他们希望的方式接受支付。

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

在所有这些设计中，保持去中心化并对用户易于理解至关重要。我们需要确保用户可以轻松访问关于他们当前资产和针对他们的消息的最新视图。这些视图应该依赖于开放工具，而不是专有解决方案。要避免支付基础设施的更大复杂性变成一个难以理解和适应新环境的不透明的"抽象之塔"，需要付出艰苦努力。尽管面临挑战，但实现以太坊的可扩展性、钱包安全性和普通用户的隐私至关重要。这不仅关乎技术可行性，还关乎对普通用户的实际可访问性。我们需要迎接这一挑战。