以太坊从一项早期的实验性技术如今转变为成熟的技术堆栈，为了使其能够真正为普通用户带来更具开放性、全球化和无需许可的使用体验，后续还需要大致同时经历三个主要的技术转变：‍‍‍

01 Layer2 (L2) 扩展转变：用户将转向 Rollups 技术；

02 钱包安全转变：用户将转向智能合约钱包；

03 隐私转变：确保资金可以在保障隐私情况下进行转移，并确保所有其他正在开发的工具（如社交恢复「译者注：Social Recovery，具体可参考 Why we need wide adoption of social recovery wallets https://vitalik.ca/general/2021/01/11/recovery.html」、身份、声誉）都是受隐私保护的；

生态系统发展的三个方向，三者均具有必要性

如果没有 L2 扩展转变，以太坊就会失败，因为每笔交易的成本为 3.75 美元（如果我们有另一次牛市则可能为 82.48 美元）。并且每个针对大众市场的产品都将不可避免地会轻视链上转而采用中心化交易的变通方法，从而降低交易成本。

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

如果没有隐私转变，以太坊就会失败，因为所有交易（和 POAP「译者注：“Proof-Of-Attendance Protocol [出席证明协议]”」等）都可公开供任何人查看，这对许多用户来说是一种过高的隐私牺牲，并且用户都将转向至少在某种程度上保护用户数据隐私的中心化解决方案。

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

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

在未来的 L2 扩展世界中，用户将存在于许多 L2 上。如果你是依赖于 Optimism 的 ExampleDAO 成员，那么你就会有一个 Optimism 帐户。如果你在 ZkSync 上的稳定币系统中持有 CDP，那么你就会有一个 ZkSync 帐户。如果你有尝试过 Kakarot 上的一些应用程序，那么你就会有一个 Kakarot 帐户。一个用户持有多个账户地址将在未来成为常态。

根据我的 Brave Wallet 观点，我在四个地方都有 ETH。Arbitrum 和 Arbitrum Nova 是不同的，随着时间的推移它会变得更加复杂

智能合约钱包增加了更多的复杂性，使得在 L1 和各种 L2 中拥有相同地址变得更加困难。如今，大多数用户都在使用外部所有者账户（EOA）「译者注：即我们平时接触到的，用户通过私钥来直接控制的账户」，其地址实际上是用于验证签名的公钥哈希值 — 因此 L1 和 L2 之间没有任何变化。然而，对于智能合约钱包，保留相同地址变得更加困难。尽管已经做了很多工作来尝试使地址成为可以跨网络等效的哈希代码，最著名的是 CREATE2 和 ERC-2470 单例工厂，但很难使这项工作完美无缺。一些 L2s（例如 “TYPE 4 ZK-EVM”）并不完全是 EVM 兼容，通常使用 Solidity 或中间组件代替，使得哈希值无法完全相等。即使你可以拥有相等的哈希值，密钥变更导致钱包所有权变更的可能性也会产生其他反直觉的结果。

对于隐私的需求会促使每个用户拥有更多地址，甚至可能会改变我们使用的地址类型。如果隐形地址「译者注：Stealth Address，具体可参考 An incomplete guide to stealth addresses https://vitalik.ca/general/2023/01/20/stealth.html」提议得到广泛使用，那么可能每笔交易都会存在一个地址，而不是目前的每个用户只有几个地址或者每个 L2 一个地址。其他的隐私方案，甚至是现有的方案例如 Tornado Cash，用通过不同方法改变了资产存储的方式：许多用户的资金存储在同一个智能合约中（因此在同一个地址）。要向特定用户发送资金，用户将需要依赖隐私方案自身的内部寻址系统。

正如我们所见，这三种转变中的每一种都以不同的方式削弱了 “一个用户约等于一个地址” 的心理模型，并且其中一些影响反而使得上述转变的执行层面变得更加复杂。其中两个特殊的复杂点是：

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

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

II. 三个转变与链上支付（身份）

假定我在 Scroll 上有代币，我想花钱买咖啡。你在卖咖啡给我，但你只能在 Taiko 上接收代币。该做什么？

基本上有两种解决方案：

• 接收钱包（可以是商家，也可以是普通个人）非常努力地支持每个 L2，并具有一些可以整合不同种资金的自动化功能；

• 收款人提供他们的 L2 和他们的地址，发件人的钱包通过一些跨 L2 桥自动将资金转移到目的地钱包地址；‍

当然，这些解决方案可以结合使用：收件人提供他们可以接受的 L2 列表，发件人的钱包在进行付款时既可能可以同链直接发送支付，也可能可以跨 L2 桥进行跨链支付。

但这里引发了三个转变所带来的更加重要的一个挑战：向某人付款的简单操作开始需要比 20 字节地址更多的信息。

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

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

隐形地址协议依赖于元地址（Meta-Addresses）的概念，它的工作方式是：元地址的一部分是发送者支出密钥的隐藏版本，另一部分是发送者的加密密钥（尽管通过很小的程序可以将两个密钥设置为相同）。

基于加密和 ZK-SNARK 的抽象隐身地址方案的示意图

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

III. 三个转变和密钥恢复

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

• Gas 费成本过高：这个是不言自明的；

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

• 隐私：如果用户故意拥有多个地址并且避免将它们相互链接，他们当然不希望在同时恢复上述地址的过程中公开这些地址的关联关系；‍

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

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

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

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

• Merkle 分支（Merkle Branches）。Merkle 分支可以将 L1 状态证明到 L2，或将 L2 状态证明到 L1，或者你可以将两者结合起来以将一个 L2 的部分状态证明到另一个 L2。Merkle 证明的主要弱点是由于证明长度导致的高 gas 成本：一个证明可能需要 5 KB。不过这点在未来基于 Vercle Tree 可以将成本减少到小于 1 KB；

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

• KZG 承诺（译者注：Kate-Zaverucha-Goldberg (KZG) polynomial commitment scheme，具体可参考 KZG polynomial commitments https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html）。L2 或建立在它们之上的方案可以引入顺序寻址系统，允许该系统内的状态证明只有 48 个字节长度。与 ZK-SNARKs 一样，多重证明方案（译者注：Multiproof Scheme，具体可参考 PCS multiproofs using random evaluationhttps://dankradfeist.de/ethereum/2021/06/18/pcs-multiproofs.html）可以将所有这些证明合并为每个块的单个证明；

‍

如果我们想避免为每笔交易都制作一个证明，我们可以实施一个更轻的解决方案，只需要一个跨 L2 证明来恢复。一个帐户中的支出将依赖于与该账户中公钥相对应的支出密钥，但恢复将需要一个交互来复制密钥库中的当前 Spending_pubkey。即使你的旧密钥不安全，反事实地址中的资金也是安全的：“激活” 反事实地址以将其转变为工作合约需要进行交叉 L2 证明以复制当前的 Spending_pubkey. Safe 论坛上的这篇文章描述了类似架构的工作原理（译者注：How can a Safe hold asset on multiple chains? https://forum.safe.global/t/how-can-a-safe-hold-asset-on-multiple-chains/2242）。

为了给此方案增加隐私属性，我们只需加密这个 Pointer，然后我们在 ZK-SNARKs 内部中进行所有证明工作：

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

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

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

使用 ENS 很昂贵。今天，即 2023 年 6 月，情况还算不错：交易费用很高，但仍可与 ENS 域名费用相媲美。注册 zuzalu.eth 花了我大约 27 美元，其中 11 美元是交易费。但如果我们有另一个牛市，费用将会飙升。即使没有 ETH 价格上涨，gas 费用回到 200 gwei 也会将域名注册的 tx 费用提高到 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 分支）。

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

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

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

• 通过 “is this an EOA?” 来判断区分用户和合约（例如，防止转账或收取使用费）的 Dapps 模式会被破坏。总的来说，我建议不要在这里寻找纯技术解决方案；弄清楚特定的密码控制转账是否是受益所有权的转移是一个难题，如果不通过一些链下社区驱动的机制可能无法解决。最有可能的是，应用程序将不得不减少对防止转账的依赖，转而更多地依赖 Harberger Tax 等技术；

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

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

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

今天，钱包也承担着保护资产的任务。由于一切都在链上，钱包唯一需要保护的是当前保护这些资产的私钥。如果你更改了密钥，你可以在第二天安全地在互联网上发布你以前的私钥。然而，在 ZK 世界中，情况将有所改变：钱包不仅保护身份验证凭据，它还保存着你的数据。

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

我的许多 Zupass 邮票之一，确认我是 Team Cat 的骄傲成员

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

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

Zupass 的实际解决方案是鼓励人们将密钥存储在多个设备（例如笔记本电脑和手机），因为用户同时无法访问所有设备的可能性很小。甚至更进一步，在多个监护人之间通过秘密共享（译者注：Secret Sharing，具体可参考 Secret Sharing and Erasure Coding https://blog.ethereum.org/2014/08/16/secret-sharing-erasure-coding-guide-aspiring-dropbox-decentralizer）来存储密钥。

这种通过 MPC 进行的社交恢复对于钱包来说并不是一个充分的解决方案，因为这意味着不仅是当前的监护人，甚至以前的监护人都可能串通窃取你的资产，这是一个不可接受的高风险。但是隐私泄露的风险通常低于总资产损失风险，并且对于隐私有极高要求的用户总是可以通过备份密钥信息来避免资产丢失的风险。

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

VI. 回到身份

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

一种方法是让 ENS 成为你的身份：你的 ENS 记录也许可以包含上述所有这些信息，如果你发送给 bob.eth（或 bob.ecc.eth，或 ...）资金，他们可以在较为复杂的跨域和隐私保护的情况下，看到有关如何与你进行转账支付和互动的所有信息。

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

• 它把太多的东西和你的名字联系在一起。你的名字不是 “你” 本身，它只是你的众多属性之一。用户应当可以在无需移动整个身份资料并更新许多应用程序中一大堆记录的情况下，更改其姓名；

• 你无法拥有无需信任的反事实名称（Counterfactual Names）。任何区块链的一个关键 UX 功能是能够将代币发送给尚未与该链交互的人。如果没有这样的功能，就会有一个问题：与链交互需要支付交易费用，而未曾交互过的地址也无法有代币去支付该交易费用。ETH 地址，包括带有 CREATE2 的智能合约地址，都具有此功能。而 ENS 名称没有此功能，因为如果两个 Bob 都在链下决定他们是 bob.ecc.eth，我们无法从中选择他们哪一个获得该名称；

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

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

不管是发送者还是接收者先行动，更多地依赖钱包直接实时生成最新的支付信息可以减少摩擦。能够长久保持不变的身份标识对于用户来说很方便（尤其是使用 ENS），但发送者和接收者之间的直接通信假设在实践技术中比较棘手，因此我们最终可能会看到不同技术的组合。

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

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

原文链接

推荐阅读