立即注册作者|Vitalik点这里查看OKEx欧易注册！
编译|@rickawsb点这里进入OKEx欧易注册！
原文链接：
点这里进入OKEx欧易注册！https://vitalik.eth.limo/general/2023/06/09/three_transitions.html
https://twitter.com/rickawsb/status/1667183665409925122
随着以太坊从一个年轻的实验性技术转变为一个成熟的技术堆栈，能够为普通用户带来开放、全球和无需许可的体验，这个堆栈需要同时经历三个重大的技术转变：
●第一个是二层扩展转变——所有人都转向二层扩展解决方案。
●第二个是钱包安全转变——所有人都转向智能合约钱包。
●第三个是隐私转变——确保提供保护隐私的资金转账方式，并确保正在开发的所有其他工具（社交恢复、身份、声誉）都保护隐私。
生态系统转换三角形，你只能从中选择 3 个
如果没有实现第一个，以太坊就会失败，因为每笔交易的成本为 3.75 美元（如果我们有另一次牛市，则为 82.48 美元），并且针对大众市场的每个产品都不可避免地会忘记区块链并为所有事情采用中心化的解决方法。
如果没有实现第二个，以太坊就会失败，因为用户不愿意存储他们的资金（和非金融资产），并且每个人都转向中心化交易所。
如果没有实现第三个，以太坊就会失败，因为所有交易（和 POAP 等）都公开供任何人查看，这对许多用户来说是一种太高的隐私牺牲，并且每个人都转向至少在某种程度上隐藏你的数据的集中式解决方案。
这三个转变对上述原因至关重要。但是由于涉及到适当解决这些问题的紧密协调，这些转变也充满挑战。需要改进的不仅仅是协议的功能；在某些情况下，我们与以太坊的交互方式也需要发生根本性的改变，这要求应用程序和钱包进行深层次的改变。
这三个转变将彻底改变用户和地址之间的关系
在二层扩展的世界中，用户将存在于许多不同的二层网络上。你是 ExampleDAO 的成员，它存在于 Optimism 上吗？那么你就在 Optimism 上有一个帐户！你在 ZkSync 上持有一个稳定币系统中的 CDP 吗？那么你就在 ZkSync 上有一个帐户！你曾经尝试过在 Kakarot 上运行的某个应用程序吗？那么你在 Kakarot 上有一个帐户！用户只有一个地址的时代将一去不复返。
根据我的 Brave 钱包视图，我在四个地方拥有以太坊。没错，Arbitrum 和 Arbitrum Nova 是不同的。别担心，随着时间的推移，情况会变得更加混乱！
智能合约钱包增加了更多复杂性，因为它使得在 L1 和各个 L2 之间拥有相同地址变得更加困难。如今，大多数用户使用的是外部拥有的帐户（EOA），其地址实际上是用于验证签名的公钥的哈希值，因此在 L1 和 L2 之间没有任何变化。然而，使用智能合约钱包时，保持一个地址变得更加困难。虽然已经做了很多工作，尝试使地址成为可以在不同网络之间等效的代码哈希（最值得注意的是 CREATE2 和 ERC-2470单例工厂），但要完美实现这一点很难。一些 L2 （例如，“第四型 ZK-EVMs”）并不完全等同于 EVM，通常使用 Solidity 或中间级别的汇编语言，从而阻止了哈希的等效性。即使可以实现哈希等效性，钱包通过密钥更改而改变所有权的可能性会产生其他令人费解的后果。
隐私要求每个用户拥有更多的地址，甚至可能会改变我们处理的地址类型。如果隐形地址提案被广泛使用，那么用户可能每次交易都会有一个地址。其他隐私方案，甚至包括现有的方案，如 Tornado Cash，以不同的方式改变了资产的存储方式：许多用户的资金存储在同一个智能合约中（因此在同一个地址上）。为了向特定用户发送资金，用户将需要依赖隐私方案自己的内部寻址系统。
正如我们所见，这三个转变以不同的方式削弱了“一个用户=一个地址”的心理模型，并且其中一些影响反过来又增加了执行这些转变的复杂性。两个特别复杂的问题是：
1、如果你想付款给某人，你将如何获取付款信息？
2、如果用户的资产存储在不同的链上的不同位置，他们如何进行密钥更改和社交恢复？
三个转变与链上支付（和身份）之间的关系
我在 Scroll 上有一些币，我想用它们买咖啡（如果"I"是指我，这篇文章的作者，那么"咖啡"当然是指"绿茶"）。你是卖给我咖啡的人，但你只能接收 Taiko 上的币。怎么办？
基本上有两个解决方案：
1、接收钱包（可以是商家，也可以是普通人）要非常努力地支持每个 L2，并具有一些自动功能，可以异步合并资金。
2、收款人在地址旁边提供他们的 L2，然后发送者的钱包通过某个跨 L2 桥接系统自动将资金路由到目标 L2。
当然，这些解决方案可以结合使用：收款人提供他们愿意接受的 L2 列表，然后发送者的钱包找出支付方式，这可能包括直接发送（如果他们很幸运）或通过跨 L2 桥接路径发送。
但这只是一个关键挑战的例子，这三个转变引入的简单操作开始需要比仅仅一个 20字节的地址更多的信息。
幸运的是，智能合约钱包的转变对寻址系统来说并不是一个巨大的负担，但在应用程序堆栈的其他部分仍然存在一些技术问题。钱包需要更新，以确保它们在交易中不仅发送 21000 Gas，而且更重要的是，确保接收方的钱包能够跟踪不仅来自 EOA 的 ETH 转账，还有由智能合约代码发送的 ETH。依赖地址所有权不可变的应用程序（例如，禁止智能合约以执行版税的 NFT）将不得不寻找其他实现目标的方法。智能合约钱包还将使某些事情变得更容易，尤其是，如果有人只收到非 ETH ERC20代币，他们将能够使用 ERC-4337 付款代理来支付该代币的 Gas 费用。
另一方面，隐私再次提出了一些我们尚未真正解决的重大挑战。最初的 Tornado Cash 没有引入任何这些问题，因为它不支持内部转账：用户只能存入系统并从中提取资金。然而，一旦可以进行内部转账，用户将需要使用隐私系统的内部寻址方案。实际上，用户的“支付信息”将需要包含以下内容：（i）某种“支付公钥”，即收款方可用于支出的一个密钥承诺，以及（ii）让发送方发送加密信息，只有收款方能够解密以帮助收款方发现付款的方式。
隐形地址协议依赖于元地址的概念，它的工作原理如下：元地址的一部分是发送方的盲化版本的花费密钥，另一部分是发送方的加密密钥（尽管最小的实现可以将这两个密钥设置为相同）。
基于加密和零知识简洁非交互式证明（ZK-SNARKs）的抽象隐私地址方案的示意概览
这里的一个关键教训是，在一个注重隐私的生态系统中，用户将同时拥有支付公钥和加密公钥，用户的“支付信息”将不得不包含这两个密钥。除了支付之外，还有其他很好的原因可以扩展到这个方向。例如，如果我们想要基于以太坊的加密电子邮件，用户将需要公开提供某种加密密钥。在“EOA 世界”中，我们可以重复使用帐户密钥，但在安全的智能合约钱包世界中，我们可能应该对此进行更明确的功能定义。这也有助于使基于以太坊的身份与非以太坊的分布式隐私生态系统更兼容，尤其是 PGP 密钥。
三个转变和密钥恢复
在一个每个用户拥有多个地址的世界中，实现密钥更改和社交恢复的默认方法是让用户分别在每个地址上运行恢复过程。这可以通过单击一次来完成：钱包可以包含执行恢复过程的软件，同时在用户的所有地址上执行。然而，即使有这样的用户体验简化，朴素的多地址恢复仍然存在三个问题：
1、Gas 成本不可行：这个问题不言而喻。
2、反事实地址：尚未发布智能合约的地址（实际上，这意味着您尚未从该帐户发送资金的帐户）。作为用户，您可能在每个L2上都有无限多个事实上的地址：包括尚不存在的 L2 上的一个或多个地址，以及从隐形地址方案中产生的另一个无限集合。
3、隐私：如果用户故意拥有多个地址以避免将它们链接到一起，他们肯定不希望通过同时恢复它们来公开地将所有地址链接起来！
解决这些问题是困难的。幸运的是，有一个相当优雅的解决方案，性能也还不错：一种体系结构将验证逻辑和资产持有分开。
每个用户都拥有一个密钥存储合约，它存在于一个位置（可以是主网或特定的 L2）。然后用户在不同的 L2 上拥有地址，每个地址的验证逻辑都是指向密钥存储合约的指针。从这些地址支出需要提供一个证明，该证明进入密钥存储合约，显示当前的（或者更现实的是非常近期的）花费公钥。
可以通过几种方式实现这个证明：
●在 L2 内直接读取 L1 状态。可以修改 L2 以使其能够直接读取 L1 状态。如果密钥存储合约在 L1 上，这意味着 L2 内的合约可以无偿访问密钥存储合约。
●Merkle 分支。Merkle 分支可以证明 L1 状态到 L2，或 L2 状态到 L1，或者可以将两者合并以证明一个 L2 的部分状态到另一个 L2。Merkle 证明的主要弱点是由于证明长度而产生的高 Gas 费用：一个证明可能需要 5KB，尽管由于 Verkle 树的原因，将来这将减少到<1KB。
●ZK-SNARKs。可以通过使用 Merkle 分支的 ZK-SNARK 的方法来减少数据成本，而不是使用分支本身。可以构建离链聚合技术（例如基于 EIP-4337），以使一个单一的 ZK-SNARK 验证一个区块中的所有跨链状态证明。
●KZG 承诺。无论是 L2 还是构建在其之上的方案，都可以引入顺序寻址系统，允许证明该系统内部状态的证明仅为 48 字节长。与 ZK-SNARKs 一样，多证明方案可以将所有这些证明合并为每个块的单个证明。
如果我们想要避免每个交易都生成一个证明，我们可以实现一个更轻的方案，只需要一个跨 L2 证明来恢复。从帐户支出取决于一个花费密钥，其对应的公钥存储在该帐户内部，但恢复需要一笔交易，将当前的花费公钥复制到密钥存储中。即使您的旧密钥丢失，计数事实上的地址中的资金也是安全的：将事实上的地址“激活”以将其转换为工作合约需要进行跨 L2 证明以复制当前的花费公钥。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）可以放在这样的合约的控制下。一旦 CCIP 合约在 L1 上控制了 ecc.eth，访问某个 subdomain.ecc.eth 将自动涉及查找和验证一个证明（例如 Merkle 分支），证明该特定子域名存储在实际存储该子域名的 L2 中。
实际获取这些证明涉及访问存储在合约中的 URL 列表，尽管这确实感觉像是中心化，但我认为它实际上并不是：这是一种 1 对 N 的信任模型（无效的证明会被 CCIP 合约回调函数中的验证逻辑捕获，只要有一个 URL 返回一个有效的证明，就可以）。URL 列表可以包含几十个 URL。
ENS CCIP 的努力是一个成功的故事，并且应该被视为这样一种迹象：我们实际上可以实现我们所需的这种根本性改革。但还需要进行许多应用层改革。以下是一些例子：
●许多dapp依赖用户提供离链签名。对于外部拥有的帐户（EOAs），这很容易。ERC-1271 提供了一种标准化的方法来实现智能合约钱包的离链签名。然而，许多 dapp 仍然不支持 ERC-1271，它们将需要进行更新。
●使用“这是 EOA 吗？”来区分用户和合约的 dapp（例如，防止转账或强制版税的 NFT）将会出现问题。总的来说，我建议不要试图在这里找到纯技术解决方案；确定特定加密控制的转移是否是有益所有权转移是一个很困难的问题，可能无法在没有一些离链社区驱动机制的情况下解决。最有可能的是，应用将不再依赖于阻止转移等技术手段，而是更多地依赖于诸如 Harberger 税之类的技术。
●钱包如何与花费和加密密钥交互将需要改进。目前，钱包经常使用确定性签名来生成应用程序特定的密钥：使用 EOA 的私钥对标准 nonce（例如应用程序名称的哈希）进行签名会生成一个确定性值，而无法在没有私钥的情况下生成，因此从纯技术上讲是安全的。然而，这些技术对于钱包来说是“不透明”的，阻止了钱包实施用户界面级别的安全检查。在一个更成熟的生态系统中，签名、加密和相关功能将需要由钱包更明确地处理。
●轻客户端（例如 Helios）将需要验证 L2，而不仅仅是 L1。今天，轻客户端主要关注检查 L1 头部的有效性（使用轻客户端同步协议），并验证以 L1 头部为根的 L1 状态和交易的 Merkle 分支。明天，它们还将需要验证以 L1 中存储的状态根为根的 L2 状态的证明（更先进的版本实际上将查看 L2 的预确认）。
钱包将需要保护资产和数据
今天，钱包的任务是保护资产。一切都存储在链上，钱包需要保护的唯一东西就是当前保护这些资产的私钥。如果更改密钥，您可以在第二天将之前的私钥安全地发布在互联网上。然而，在 ZK 世界中，情况就不再如此：钱包不仅仅是保护身份验证凭据，它还保存着您的数据。
我们在 Zuzalu 上看到了这种世界的最初迹象，Zuzalu 使用了基于 ZK-SNARK 的身份系统 Zupass。用户拥有一个私钥，用于在系统中进行身份验证，该私钥可以用于生成基本证明，例如“证明我是一个 Zuzalu 居民，而不泄露我的具体身份”。但是，Zupass 系统还开始在此之上构建其他应用，最重要的是 stamp（ Zupass 版本的 POAP）。
我的许多Zupassstamp之一，确认我是TeamCat的骄傲成员
stamp 相对于 POAP 的主要特点是隐私性：您在本地保存数据，只有在希望将其提供给其他人时，才会对 stamp （或 stamp 计算中的一些计算）进行 ZK 证明。但这也带来了一定的风险：如果您丢失了这些信息，就会失去您的 stamp 。
当然，持有数据的问题可以减少到持有单个加密密钥的问题：某个第三方（甚至是链）可以持有对数据的加密副本。这具有方便的优势，即您采取的操作不会更改加密密钥，因此不需要与保护您的加密密钥的系统进行任何交互。但即使如此，如果您丢失了加密密钥，您将失去所有内容。而且，反过来，如果有人看到了您的加密密钥，他们将看到所有加密给该密钥的内容。
Zupass 的实际解决方案是鼓励人们将密钥存储在多个设备上（例如笔记本电脑和手机），因为他们在同一时间失去所有设备的几率是微小的。我们可以进一步采用通过秘密共享将密钥存储在多个保护者之间的方案。
这种通过 MPC 进行的社交恢复不足以成为钱包的解决方案，因为它意味着不仅当前保护者，而且先前的保护者都可能合谋窃取您的资产，这是一个无法接受的高风险。但是隐私泄漏通常比完全丧失资产的风险较低，一个对隐私需求较高的用例可以始终接受更高的损失风险，即不备份与这些隐私需求相关的密钥。
为了避免让用户陷入一个繁琐的多重恢复路径系统中，支持社交恢复的钱包可能需要同时管理资产恢复和加密密钥恢复。
回到身份问题
这些变化的一个共同线索是“地址”这个概念，即您在链上用来代表“您”的加密标识符，将会发生根本性的变化。关于“如何与我互动”的指令将不再仅仅是一个 ETH 地址；在某种形式上，它们将是多个地址、多个 L2 上的地址、隐形元地址、加密密钥和其他数据的组合。
实现这一点的一种方法是将 ENS 作为您的身份：您的 ENS 记录可以包含所有这些信息，如果您发送给某人 bob.eth（或 bob.ecc.eth 等），他们可以查找并查看与您进行支付和互动的所有信息，包括更复杂的跨域和隐私保护方式。
但是，这种以 ENS 为中心的方法存在两个弱点：
●它将太多的事物与您的名字绑定在一起。您的名字并不是您本人，您的名字只是您的众多属性之一。应该可以更改您的名字而不需要转移整个身份配置文件并更新许多应用程序中的记录。
●您无法拥有可信的假名。任何区块链的一个关键用户体验功能是能够将币发送给尚未与该链进行交互的人。没有这样的功能，就会陷入进退两难的境地：与链进行交互需要支付交易费，而支付交易费又需要...已经拥有币。ETH 地址，包括带有 CREATE2 的智能合约地址，具备这种功能。ENS 名称没有，因为如果两个 Bob 都在链下决定他们是 bob.ecc.eth ，就没有办法选择谁将获得该名称。
一种可能的解决方案是在先前在本文中提到的体系结构中将更多内容放入keystore合约。keystore 合约可以包含关于您以及如何与您互动的各种信息（并且使用 CCIP，其中一些信息可以在链下），用户将使用其 keystore 合约作为主要标识符。但是他们实际收到的资产将存储在各种不同的地方。Keystore 合约不与名称绑定，并且具有友好的反事实性：您可以生成一个地址，该地址可以被证明只能由具有某些固定初始参数的 keystore 合约初始化。
另一类解决方案涉及彻底放弃用户可见的地址概念，类似于比特币支付协议。一个想法是更多地依赖发送方和接收方之间的直接通信渠道；例如，发送方可以发送一个认领链接（可以是显式的 URL 或二维码），接收方可以使用该链接以自己希望的方式接受支付。
无论发送方还是接收方先行动，更多地依赖钱包在实时生成最新的付款信息方面的可能性可以减少摩擦。然而，直接沟通的假设在实践中确实是一个棘手的问题，因此我们可能最终会看到不同技术的组合。
在所有这些设计中，保持分散化并让用户能够轻松访问其当前资产和为他们发布的消息的最新视图至关重要。这些视图应该依赖于开放工具，而不是专有解决方案。努力避免支付基础架构的更大复杂性变成一个不透明的“抽象之塔”，使开发者很难理解正在发生的事情并将其适应新的环境，这是一项艰巨的任务。尽管存在挑战，但为普通用户实现可扩展性、钱包安全性和隐私对以太坊的未来至关重要。这不仅关乎技术可行性，还关乎普通用户的实际可访问性。我们需要努力迎接这个挑战。
点这里查看OKEx欧易注册！
本文内容部分来自网络，仅供参考。如有侵权，请联系删除。