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

随着以太坊从年轻的实验技术成长为成熟的技术堆栈，以便为普通用户提供一个开放、全球化且无需许可的体验，我们需要同时推进三个关键的技术转型：

• L2 扩容转型 —— 人人都使用 Rollups
• 钱包安全转型 —— 人人都使用智能合约钱包
• 隐私转型 —— 保障资金转移的隐私保护，并确保正在开发的其他工具（如社交恢复、身份验证、声誉系统）同样注重隐私保护

这三个转型构成了生态系统转型的三角形，必须全面实施，不可偏废。

缺乏第一项转型，以太坊将因交易成本高昂（每笔交易成本为3.75美元，牛市期间可高达82.48美元）而失败，每个面向大众市场的产品最终都会放弃链上解决方案，转而采用中心化方案。

缺乏第二项转型，以太坊将因用户不愿意存储他们的资金和非金融资产而失败，人们纷纷转向中心化交易所。

缺乏第三项转型，以太坊也将失败，因为所有交易和活动（如 POAP 等）都能被任何人公开查看，这对许多用户而言是隐私上无法接受的牺牲，导致人们转向至少能在某种程度上隐藏数据的中心化解决方案。

这三项转型不仅至关重要，而且充满挑战，需要密切协调以正确解决。这不仅仅是协议功能的改进；在某些情况下，我们与以太坊互动的方式需要根本性的变化，这要求应用程序和钱包进行深刻的改革。

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

这三种变革将彻底改变用户与地址之间的关系。在L2扩容技术的背景下，用户将分布在众多的L2网络中。例如，如果你是Optimism网络上ExampleDAO的一员，那么你就拥有一个Optimism账户；如果你在ZkSync的稳定币系统中持有CDP，那么你就有一个ZkSync账户；如果你曾尝试过在Kakarot网络上使用某个应用，那么你就拥有一个Kakarot账户。用户仅拥有一个地址的时代即将结束。

据我通过Brave Wallet查看，我的ETH分布在四个地方。没错，Arbitrum和Arbitrum Nova是两个不同的平台。但别担心，事情会随着时间而变得更加复杂！ 智能合约钱包的引入增加了复杂性，使得在L1和各个L2上保持同一个地址变得更加困难。目前，大多数用户都在使用外部拥有账户，其地址实际上是公钥哈希，这意味着在L1和L2之间的地址不会改变。然而，使用智能合约钱包后，保持单一地址变得更加困难。尽管人们尽力让地址可以通过代码的哈希在不同网络间等效，特别是通过CREATE2和ERC-2470单例工厂，但要完美实现这一点仍然充满挑战。某些L2（例如“第四类型的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 支付大师使用该代币支付交易费用。

另一方面，隐私保护再次成为我们尚未彻底解决的重大挑战。Tornado Cash 的原始版本并未引入这些问题，因为它不支持内部转账：用户只能存入和提取。但一旦允许内部转账，用户就需要使用隐私系统的内部地址方案。实际上，用户的“支付信息”应包含（i）一种“支付公钥”，接收方可以利用这个承诺来进行支付，以及（ii）发送方发送的只有接收方能解密的加密信息，帮助接收方识别支付。

隐形地址协议基于元地址概念，其工作机制是：元地址的一部分是发送方支付密钥的盲化版本，另一部分是发送方的加密密钥（虽然最简实现可以将这两个密钥设置为同一个）。

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

基于加密和零知识证明（ZK-SNARKs）的隐形地址方案概览显示，隐私友好生态系统中的用户需要同时拥有支付公钥和加密公钥，并且用户的支付信息必须包括这两种密钥。除了支付外，扩展这一方向还有其他好处。例如，若我们希望实现基于以太坊的加密电子邮件，用户需要公开某种加密密钥。在传统的账户体系中，我们可能重新使用账户密钥，但在安全的智能合约钱包体系中，我们可能需要更明确的功能。这也有助于使基于以太坊的身份解决方案与非以太坊去中心化隐私生态系统（尤其是 PGP 密钥）更加兼容。

三个转变和密钥变更

在用户拥有多个地址的情况下，默认实施密钥更换和社交恢复的方式是让用户对每个地址分别执行恢复流程。这个过程可以通过一键完成：钱包软件能够一次性跨所有用户地址执行恢复操作。然而，尽管这种方式简化了用户体验，但简单的多地址恢复存在三大问题：

1. 高昂的gas费：这个问题不需要过多解释。
2. 反事实地址：尚未发布智能合约的地址（实际上，这意味着你还没有从该账户发送过资金）。作为一个用户，你可能拥有无限多的反事实地址：在每一个二层网络（L2）上都可能有一个或多个，包括那些尚未出现的L2，以及由隐式地址方案产生的无穷尽的反事实地址集。
3. 隐私问题：如果用户特意使用多个地址来防止它们被相互关联，他们肯定不会希望通过同时恢复所有地址来公开地将它们关联起来。

解决这些问题非常困难。幸运的是，有一个相对优雅的方案能够相当有效地解决这些问题：一个将验证逻辑和资产持有分开的架构。

每个用户都有一个密钥库合约，这个合约位于一个特定位置（可以是主网或某个特定的二层网络L2）。然后，用户在不同L2上会有不同的地址，这些地址的验证逻辑是指向密钥库合约的引用。从这些地址进行转账需要向密钥库合约提交一个证明，证明显示了当前（或更现实地说，非常近期的）交易公钥。这种证明可以通过几种方式实现：

• 在L2内部直接只读访问L1。可以修改L2以实现直接读取L1状态的功能。如果密钥库合约位于L1上，这意味着L2内的合约可以“免费”访问密钥库。
• Merkle 分支能够验证 L1 到 L2 的状态，反之亦然，或者将两者结合起来，实现一个 L2 对另一个 L2 状态部分的验证。Merkle 证明的一个主要缺点是因为证明的长度而造成的高 gas 消耗：一个证明可能需要 5 kB，但得益于 Verkle 树的发展，这个数字将来会降低到小于 1 kB。
• ZK-SNARKs 可以通过使用 Merkle 分支的 ZK-SNARK 而非分支本身来降低数据成本。可以在 EIP-4337 基础上开发离线聚合技术，用单一的 ZK-SNARK 验证一个区块中所有跨链状态的证明。
• KZG 承诺可以通过 L2s 或在其基础上建立的方案引入序列地址系统，使得系统内状态的证明仅需 48 字节。和 ZK-SNARKs 类似，可以通过多重证明方案，将所有证明合并为每个区块的单一证明。

如果我们希望避免对每笔交易都进行单独证明，可以采用一种仅在恢复时需要跨 L2 证明的更轻量化方案。账户的支出将依赖于一个与账户内存储的公钥相对应的支出密钥，而恢复过程则需要一笔交易来更新密钥库中的当前 spending_pubkey。即使旧密钥不再安全，计划中地址里的资金也是安全的，激活一个计划中地址成为有效合约需要通过跨 L2 证明更新当前的 spending_pubkey。Safe 论坛上的讨论介绍了如何实现类似的架构。

为了增加隐私，我们可以加密指向信息的指针，并在 ZK-SNARKs 内部完成所有验证工作：

进一步的研究（例如，以当前工作为基础）也许能简化 ZK-SNARKs 的复杂度，发展出一个更简化的基于 KZG 的方案。

虽然这些方案可能相当复杂，但它们之间存在很多潜在的协同效应。比如，”密钥库合约”的概念可以解决前文提及的地址问题：若我们想要用户有一个固定不变的地址，不因密钥更新而改变，我们可以将隐形地址、加密密钥等信息存入密钥库合约，并把该合约地址作为用户的固定地址。

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

使用 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，就可以置于此类合约的控制之下。一旦 L1 的 ecc.eth 受 CCIP 合约控制，访问任何 subdomain.ecc.eth 都将自动触发查找并验证证明的过程（例如，Merkle 分支），以证实 L2 真实存储了该子域名。

获取这些证明实际上需要访问合约中列出的一系列 URL。尽管这看起来有点像集中化管理，但我认为实际上并非如此：这属于 1-of-N 信任模型（CCIP 合约的回调函数中的验证逻辑会拦截任何无效证明，只要任一 URL 返回了有效证明，就可以认为是安全的）。这个 URL 列表可能包含数十个地址。

ENS CCIP 项目的成功是一个里程碑，它证明了我们迫切需要的根本性改革是完全可能的。但在应用层面，还需要进行更多的改革。例如：

• 许多去中心化应用（DApp）依赖于用户提供的链下签名。对于个人拥有的账户（EOA）来说，这很简单。ERC-1271 为智能合约钱包提供了一种标准做法，但许多 DApp 还不支持 ERC-1271，这需要改变。
• 一些 DApp 通过判断“这是一个个人账户（EOA）吗？”来区分用户和合约（比如，为了阻止转账或执行版税），这种做法将不再适用。通常，我不建议仅寻求技术解决方案，因为确定一次加密控制权转移是否涉及实际所有权转让是一个复杂问题，可能无法通过纯技术手段解决，而需要依靠链下的社区驱动机制。应用很可能需要减少对阻止转移的依赖，转而采用像 Harberger 税这样的方法。
• 钱包在处理支出和加密密钥时的互动方式也需要改进。目前，钱包通常使用确定性签名来生成特定应用的密钥：用 EOA 的私钥签名一个标准随机数（如应用的名称哈希）会产生一个独特的值，这在技术上是安全的，但这种方式对钱包来说是不透明的，阻碍了在用户界面层面进行安全检查。在一个更成熟的生态系统中，钱包需要更明确地处理签名、加密及相关功能。
• 轻客户端（如 Helios）将需要验证 L2 以及 L1。目前，它们主要关注验证 L1 区块头的有效性，并验证根植于 L1 区块头的 L1 状态和交易的 Merkle 分支。将来，它们还需要验证根植于 L1 中的状态根的 L2 状态的证明（更进一步的版本可能会考虑 L2 的预确认）。

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

当前，钱包的核心职责是确保资产的安全。所有资产均存储于区块链上，钱包需保护的关键是那把守护资产的私钥。换了密钥后，你甚至可以在次日把旧私钥公开网络。但在零知识证明（ZK）技术面前，这一切都改变了：钱包的职责不再局限于认证信息的保护，还扩展到了数据的保管。

Zupass，一个在 Zuzalu 使用的基于 ZK-SNARK 技术的身份验证系统，预示了这一变革。用户通过私钥认证，进行如“证明我是 Zuzalu 居民，但不具体指明是谁”的基础证明。Zupass 系统还孕育了更多应用，尤其是其版本的 POAPs——邮票。

比如，我就有一个 Zupass 邮票，证明我是“猫咪队”的自豪成员。

邮票的独特之处在于其私密性：数据由用户本地保存，只有当用户希望别人知道自己的某些信息时，才会通过 ZK-证明分享邮票或相关数据。这同时带来了新的风险：一旦信息丢失，邮票也随之不翼而飞。

理论上，数据保护可以归结为保护一个加密密钥：第三方（或连本身）可以保存一份加密的数据副本。这样做的好处是，用户的操作不会改变加密密钥，也就无需与保存密钥的系统互动。但问题在于，一旦密钥丢失，一切也都丢失了。反之，密钥一旦被他人获取，那么所有加密数据都将暴露无遗。

Zupass 的事实解决方案是鼓励人们在多个设备上（例如笔记本电脑和手机）存储他们的密钥，因为他们同时失去对所有设备的访问权的几率非常小。我们可以更进一步，使用秘密共享技术在多个守护者之间分割存储密钥。通过 MPC 进行的这种社交恢复并不是钱包的足够解决方案，因为这意味着不仅当前的守护者，而且以前的守护者也可能串通一气窃取你的资产，这是一个无法接受的高风险。但是，隐私泄露通常比完全资产损失的风险低，对于有高隐私需求的使用案例的人来说，他们总是可以通过不备份与那些隐私需求行动相关的密钥来接受更高的损失风险。为了避免让用户面对一个拜占庭式的多重恢复路径系统感到不堪重负，支持社交恢复的钱包可能需要同时管理资产恢复和加密密钥恢复。

回到身份问题

这些变化共同指向了一个事实：即代表个人在区块链上身份的“地址”概念，必将经历根本性的转变。未来，代表个人身份的不仅仅是一个以太坊(ETH)地址；而是需要以某种方式，结合多个第二层网络(L2)的地址、匿名元地址、加密密钥及其他数据。将以太坊名称服务(ENS)作为身份识别的一种方式是可行的：你的ENS记录能包含所有这些信息。当某人向你的ENS地址（如bob.eth或bob.ecc.eth）发送时，他们能够获取所有必要的支付与互动信息，即使在跨域与隐私保护的更复杂场景下也是如此。

然而，这种以ENS为核心的身份认证方法存在两大问题：

• 首先，它将过多的信息与你的名字绑定。你的名字仅是你众多属性中的一个，并且理应允许在不移动整个身份档案和更新众多应用记录的情况下更改名字。
• 其次，你不能拥有一种不需信任的、所谓的“反事实”名字。区块链上的一个关键特性是能够向那些还未与链上互动的人发送代币。若没有这一功能，就会出现一个悖论：需要先拥有代币才能支付交易费用。尽管使用CREATE2的智能合约地址拥有这一特性，ENS名称却做不到，因为如果存在两个声称自己为bob.ecc.eth的Bob，在链下无法决定哪一个才是真正的拥有者。

一种潜在的解决策略是，在文章前段提及的体系架构内，向密钥存储合约中增加更多元素。密钥存储合约能够包含关于你及如何与你互动的各类信息（通过 CCIP，部分信息还可以存储于链下），而用户则将其密钥存储合约作为主要身份标识。但是，他们实际接收的资产，将被保管在多个不同的位置。密钥存储合约并不与特定名称绑定，且对反事实操作友好：即你可以创建一个地址，这个地址仅能通过具备某些特定初始参数的密钥存储合约来初始化。

另一个解决方案类别涉及彻底放弃面向用户的地址概念，这与比特币支付协议的理念相符。一个思路是更多依赖于发送者和接收者之间的直接通信渠道；例如，发送者可以发送一个声明链接（无论是以明确的 URL 形式还是二维码），接收者则可以通过他们希望的任何方式来接收付款。

无论是发送者还是接收者首先行动，更多地依赖钱包直接实时生成最新的支付信息可以减少摩擦。尽管如此，持久的标识符是方便的（特别是与 ENS 相关），并且在实践中，发送者和接收者之间的直接通信的假设是一个非常棘手的问题，因此我们可能会看到不同技术的结合。

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

声明：

1. 本文转载自[vitalik]，著作权归属原作者[Vitalik Buterin]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。