{"content":{"title":"以太坊协议的可能未来 #6 - The Splurge","body":"## 以太坊协议的可能未来，第六部分：The Splurge\r\n\r\n\r\n**特别感谢 Justin Drake、Tim Beiko 和 Yoav Weiss 提供的反馈和审阅** \r\n\r\n有些事情很难仅归入一个类别。在以太坊协议设计中，有许多“小事情”对以太坊的成功非常重要，但它们并不适合更大的子类别。实际上，其中大约一半与各种类型的 EVM 改进有关，其余则由各种小众话题组成。这就是“The Splurge”的意义所在。\r\n\r\n\r\n\r\n### The Splurge：关键目标\r\n\r\n* 将 EVM 提升至高性能和稳定的“最终状态”\r\n* 将账户抽象引入协议，使所有用户都能享受更加安全和便利的账户\r\n* 优化交易费用经济，提高可扩展性，降低风险\r\n* 探索可以使以太坊在长期内更好的先进密码学\r\n\r\n### 本章内容\r\n\r\n* [EVM 改善](https://vitalik.eth.limo/general/2024/10/29/futures6.html#1)\r\n* [账户抽象](https://vitalik.eth.limo/general/2024/10/29/futures6.html#2)\r\n* [EIP-1559 改进](https://vitalik.eth.limo/general/2024/10/29/futures6.html#3)\r\n* [VDFs](https://vitalik.eth.limo/general/2024/10/29/futures6.html#4)\r\n* [模糊化和一次性签名：密码学的远期未来](https://vitalik.eth.limo/general/2024/10/29/futures6.html#5)\r\n\r\nEVM 改善\r\n\r\n它解决了什么问题？今天的 EVM 很难进行静态分析，这使得很难创建高效的实现、形式化验证代码和随时间进行进一步扩展。此外，它的效率非常低，因此很难实现许多形式的先进密码学，除非通过预编译显式支持它们。\r\n\r\n它是什么？它是如何工作的？\r\n\r\n当前 EVM 改进路线图中的第一步计划在下一个硬分叉中引入的是 [EVM 对象格式（EOF）](https://evmobjectformat.org/)。EOF 是一系列 [EIPs](https://eips.ethereum.org/EIPS/eip-7692)，指定了一种新的 EVM 代码版本，具有许多独特的特性，最明显的是：\r\n\r\n* **代码**（可执行，但从 EVM 中不可读）和 **数据**（可读，但不可执行）之间的分离\r\n* **禁止动态跳转**，只有静态跳转。\r\n* EVM 代码 **无法观察 gas** 相关信息。\r\n* 添加了新的显式 **子程序** 机制。\r\n\r\n\r\n\r\n旧式合同将继续存在且可创建，尽管最终可能会有逐步弃用旧式合同（甚至强制将其转换为 EOF 代码）的路径。新式合同将受益于 EOF 带来的效率提升——首先，通过利用子程序特性获得稍小的字节代码，其次，通过 EOF 特定的新特性或 EOF 特定的 gas 成本降低。\r\n\r\n在引入 EOF 后，进一步更新将更容易进行。今天发展最成熟的是 [EVM 模块算术扩展（EVM-MAX）](https://eips.ethereum.org/EIPS/eip-6690)。EVM-MAX 创建了一组专门为模块算术设计的新操作，并将它们放入一个新的内存空间，该空间不能通过其他操作码访问。这使得使用优化成为可能，比如 [Montgomery 乘法](https://en.wikipedia.org/wiki/Montgomery_modular_multiplication)。\r\n\r\n一个较新的想法是将 EVM-MAX 与单指令多数据（SIMD）功能结合。SIMD 作为以太坊的一个想法已经存在很长时间，从 [Greg Colvin 的 EIP-616](https://eips.ethereum.org/EIPS/eip-616) 开始。SIMD 可以用于加速许多形式的密码学，包括哈希函数、32 位 STARKs 和基于格的密码学。EVM-MAX 加上 SIMD 使之成为 EVM 性能导向扩展的自然组合。\r\n\r\n一个组合 EIP 的近似设计是以 [EIP-6690](https://eips.ethereum.org/EIPS/eip-6690) 为起点，然后：\r\n\r\n* 允许 (i) 任何奇数或 (ii) 任何高达 2768 的 2 的幂作为模数\r\n* 对每个 EVMMAX 操作码（`add`、`sub`、`mul`）添加一个版本，该版本不仅接受 3 个立即数 `x`, `y`, `z`，而是接受 7 个立即数：`x_start`, `x_skip`, `y_start`, `y_skip`, `z_start`, `z_skip`, `count`。在 Python 代码中，这些操作码将执行类似于以下操作：\r\n\r\n```\r\nfor i in range(count):\r\n mem[z_start + z_skip * count] = op(\r\n mem[x_start + x_skip * count],\r\n mem[y_start + y_skip * count]\r\n )\r\n```\r\n\r\n但在实际实现中，它将并行处理。\r\n\r\n* 可能添加 `XOR`、`AND`、`OR`、`NOT` 和 `SHIFT`（循环和非循环），至少对于 2 的幂模数。也添加 `ISZERO`（将输出推送到 EVM 主堆栈） \r\n\r\n这将足够强大，以实现椭圆曲线密码学、小字段密码学（例如 Poseidon、circle STARKs）、常规哈希函数（例如 SHA256、KECCAK、BLAKE）和基于格的密码学。\r\n\r\n其他 EVM 升级也可能是可行的，但到目前为止，它们受到了更少的关注。\r\n\r\n#### 现有研究的一些链接有哪些？\r\n\r\n* EOF: \r\n* EVM-MAX: \r\n* SIMD: \r\n\r\n#### 剩下的工作是什么，权衡是什么？\r\n\r\n目前，EOF 计划在下一个硬分叉中引入。虽然总是有可能将其移除——功能曾在最后时刻从硬分叉中移除——但这样做将是一场艰难的战斗。移除 EOF 将意味着任何未来对 EVM 的升级都将不包括 EOF，尽管这是可行的，但可能更加困难。\r\n\r\nEVM 中的主要权衡是 L1 复杂性与基础设施复杂性。EOF 是需要添加到 EVM 实现中的大量代码，并且静态代码检查相当复杂。作为交换，我们获得了更高层语言的简化，对 EVM 实现的简化和其他好处。可以说，优先考虑继续改善以太坊 L1 的路线图会包括并基于 EOF。\r\n\r\n需要完成的一项重要工作是实现类似 EVM-MAX 加上 SIMD 的方式，并基准测试各种密码操作所需的 gas。\r\n\r\n#### 它是如何与路线图的其他部分相互作用的？\r\n\r\nL1 调整其 EVM 使得 L2 做同样的事情变得更容易。它们之间的单独调整会产生一些不兼容，这会带来自己的缺点。此外，EVM-MAX 加上 SIMD 可以降低许多证明系统的 gas 成本，从而使 L2 更加高效。它还使得通过用能够执行相同任务的 EVM 代码来替代更多的预编译变得更加容易，而这可能不会给效率带来较大的惩罚。\r\n\r\n账户抽象\r\n\r\n它解决了什么问题？今天，交易只能通过一种方式进行验证：ECDSA 签名。最初，账户抽象旨在超越这一点，允许账户的验证逻辑成为任意 EVM 代码。这可以启用一系列应用：\r\n\r\n* 切换到抗量子密码学\r\n* 轮换旧密钥（普遍被认为是一种[推荐的安全实践](https://cloud.google.com/kms/docs/key-rotation)）\r\n* 多签名钱包和 [社交恢复钱包](https://learnblockchain.cn/article/11589)\r\n* 使用一个密钥签署低价值操作，使用另一个密钥（或密钥集）签署高价值操作\r\n* 允许隐私协议在没有中继的情况下工作，从而显著降低其复杂性并消除一个关键的中心化依赖点\r\n\r\n自从 2015 年账户抽象开始以来，目标扩展为包括大量的“便利目标”，例如一个没有 ETH 但有一些 ERC20 的账户能够用该 ERC20 支付 gas。账户抽象路线图旨在不仅抽象验证，而是抽象一切：身份验证（谁可以执行操作）、授权（他们可以做什么）、重放保护、gas 支付和执行。这些目标的总结如下图所示：\r\n\r\n\r\n\r\nMPC 这里是 **多方计算**：一种 [已有 40 年历史的技术](https://research.cs.wisc.edu/areas/sec/yao1982-ocr.pdf)，将一个密钥分成多个部分，存储在多台设备上，并使用密码学技术生成签名，而不直接结合密钥的部分。\r\n\r\n[EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) 是计划在下一个硬分叉中引入的 EIP。EIP-7702 是日益认识到需要将账户抽象的便利性福利提供给所有用户，包括 EOA 用户，以改善短期内所有人的用户体验，避免分化为两个生态系统的结果。这项工作始于 [EIP-3074](https://eips.ethereum.org/EIPS/eip-3074)，最终 culminated in [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702)。EIP-7702 使账户抽象的“便利功能”向所有用户可用，包括 **EOAs**（**外部拥有账户**，即通过 ECDSA 签名控制的账户）。\r\n\r\n从图表中可以看到，虽然一些挑战（尤其是“便利”挑战）可以通过如多方计算或 EIP-7702 等增量技术解决，但促使最初账户抽象提案的安全目标大部分只能通过回归并解决原始问题来解决：允许智能合约代码控制交易验证。至今未能做到的原因是安全实现这一点具有挑战性。\r\n\r\n#### 它是什么，如何运作？\r\n\r\n从本质上讲，账户抽象是简单的：允许智能合约启动交易，而不仅仅是 EOAs。所有复杂性源于以一种有利于维护去中心化网络并防止拒绝服务攻击的方式做到这一点。\r\n\r\n一个典型的示例是多重无效化问题：\r\n\r\n\r\n\r\n如果有 1000 个账户的验证函数都依赖于某个单一值 `S`，并且 mempool 中的交易在当前 `S` 的值下是有效的，那么单个交易翻转 `S` 的值可能会使 mempool 中的所有其他交易失效。这允许攻击者通过发送垃圾交易堵塞 mempool，以非常低的成本耗尽网络节点的资源。\r\n\r\n多年的努力试图扩展功能的同时限制 DoS 风险，最终达成了实现“理想账户抽象”的解决方案：ERC-4337。\r\n\r\n\r\n\r\nERC-4337 通过将用户操作的处理分为 **验证** 和 **执行** 两个阶段来工作。所有验证首先处理，所有执行在第二阶段处理。在 mempool 中，只有在用户操作的验证阶段仅触及其自身账户（加上少数特殊情况的扩展，参见 [ERC-7562](https://eips.ethereum.org/EIPS/eip-7562) 中的“关联存储”）且没有读取环境变量时，该操作才会被接受。这防止了多重无效化攻击。还对验证步骤施加了严格的 gas 上限。\r\n\r\nERC-4337 被设计为一个额外协议标准（一个 ERC），因为当时以太坊客户端开发者专注于合并，没有闲置的能力来处理其他功能。这就是为什么 ERC-4337 使用了它称之为用户操作的对象，而不是常规的交易。最近，我们意识到有必要将至少部分其内容纳入协议。两个关键原因是：\r\n\r\n1. EntryPoint 作为合约的固有低效性：每个打包有大约 10 万 gas 的开销，每个用户操作多几千\r\n2. 需要确保以太坊属性，如通过包含列表生成的包含保证，延续到账户抽象用户。\r\n\r\n此外，ERC-4337 增加了两个功能：\r\n\r\n* **支付者（Paymasters）**：允许一个账户代替另一个账户支付费用的功能。这违反了验证阶段只能访问发送者账户本身的规则，因此引入了特殊处理以确保支付者机制是安全的。\r\n* **聚合器（Aggregators）**：支持签名聚合的功能，例如 BLS 聚合或基于 SNARK 的聚合。这是为了在滚动层上实现最高级别的数据效率。\r\n\r\n#### 现有研究的一些链接有哪些？\r\n\r\n* 关于账户抽象历史的演示：\r\n* ERC-4337: \r\n* EIP-7702: \r\n* BLSWallet 代码（使用聚合特性）：\r\n* ERC-7562（账户抽象的 mempool 规则的正式内容）：\r\n* EIP-7701（基于 EOF 的正式账户抽象）：\r\n\r\n#### 剩下的工作是什么，权衡是什么？\r\n\r\n主要剩下的工作是如何将账户抽象完全纳入协议。最近流行的正式账户抽象 EIP 是 [EIP-7701](https://eips.ethereum.org/EIPS/eip-7701)，它将在 EOF 之上实现账户抽象。一个账户可以有一个单独的代码部分用于验证，如果一个账户设置了该代码部分，该代码将在该账户的交易验证步骤中执行。\r\n\r\n\r\n\r\n这个方法的迷人之处在于，它清晰地表明有两种等效的方法来查看原生账户抽象：\r\n\r\n1. EIP-4337，但作为协议的一部分\r\n2. 一种新类型的 EOA，其中签名算法是 EVM 代码执行\r\n\r\n如果我们从对可以在验证期间执行的代码的复杂性设定严格边界——不允许访问外部状态，甚至一开始将 gas 上限设定得过低以至于对抗量子抵抗或隐私保护应用毫无用处——那么这种方法的安全性是非常明显的：它只是交换 ECDSA 验证和 EVM 代码执行，两者所需的时间相似。然而，随着时间的推移，我们需要放宽这些边界，因为 **让隐私保护的应用不依赖中继工作，以及抗量子性，都非常重要**。为了做到这一点，我们确实需要找到更灵活的方式来应对 DoS 风险，而无需将验证步骤设定得高度简约。\r\n\r\n主要的权衡似乎是“尽早将一个较少人满意的东西正式化”与“等待更长时间，也许能得到更理想的解决方案”。理想的方法很可能是某种混合方法。一种混合方法是更快地正式化一些用例，留出更多时间来思考其他用例。另一个是在 L2 上首先部署更雄心勃勃的账户抽象版本。然而，这面临一个挑战，即为了让 L2 团队愿意进行工作的采纳提案，他们需要有信心 L1 和/或其他 L2 未来将采用某种兼容的内容。\r\n\r\n我们还需要显式地思考另一个应用：**[密钥存储账户](https://vitalik.eth.limo/general/2023/06/09/three_transitions.html#the-three-transitions-and-key-recovery)**，它在 L1 或专用 L2 上存储与账户相关状态，但可以在 L1 和任何兼容 L2 上使用。有效的做到这一点，可能需要 L2 支持类似 [`L1SLOAD`](https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388) 或 [`REMOTESTATICCALL`](https://github.com/ethereum-optimism/ecosystem-contributions/issues/76) 等操作码，但这也要求在 L2 上实现账户抽象以支持此功能。\r\n\r\n#### 它是如何与路线图的其他部分相互作用的？\r\n\r\n包含列表需要支持账户抽象的交易。在实践中，包含列表的需求和去中心化 mempool 的需求其实相当相似，尽管对于包含列表会有稍微更多的灵活性。此外，账户抽象的实现应尽可能在 L1 和 L2 上进行和谐统一。如果未来我们期望大多数用户使用密钥存储滚动，则账户抽象设计应当以此为基础。Gas 支付抽象也应当在跨链用例方面进行设计（例如，参见 [RIP-7755](https://ethereum-magicians.org/t/rip-7755-contract-standard-for-cross-l2-calls-facilitation/20776)）。\r\n\r\nEIP-1559 改进\r\n\r\n它解决了什么问题？\r\n\r\n[EIP-1559](https://notes.ethereum.org/@vbuterin/eip-1559-faq) 于 2021 在以太坊激活，导致平均区块包含时间显著改善。\r\n\r\n\r\n\r\n然而，当前 EIP-1559 的实现存在几个方面的不完美：\r\n\r\n* 公式略有缺陷：它不是针对 50% 区块，而是目标在 ~50-53% 的满区块，具体取决于方差（这与数学家所称的“[AM-GM 不等式](https://en.wikipedia.org/wiki/AM%E2%80%93GM_inequality)”有关）\r\n* 在极端情况下，它 [调整得不够快](https://kclpure.kcl.ac.uk/ws/portalfiles/portal/180741021/Transaction_Fees_on_a_Honeymoon_Ethereums_EIP_1559_One_Month_Later.pdf)。\r\n\r\n随后用于 blob 的公式 ([EIP-4844](https://www.eip4844.com/)) 被明确设计来解决第一个问题，并且总体上更清晰。无论是 EIP-1559 本身，还是 EIP-4844，都没有尝试解决第二个问题。因此，现状是一个涉及两种不同机制的模糊状态，随着时间的推移，可能两者都需要改进。\r\n\r\n此外，还有一些独立于 EIP-1559 的以太坊资源定价的其他弱点，但是可以通过对 EIP-1559 的调整解决。其中一个主要问题是 **平均情况与最坏情况下的差异**：以太坊中的资源价格必须设定为能够处理最坏情况，其中整个区块的 gas 消耗占用一个资源，但平均情况的使用远低于此，导致了低效率。\r\n\r\n\r\n\r\n#### 它是什么，如何运作？\r\n\r\n解决这些低效问题的一种方法是 [多维 gas](https://learnblockchain.cn/article/10955)：对不同资源使用单独的价格和限制。该概念在技术上独立于 EIP-1559，但 EIP-1559 使其更容易实现：不使用 EIP-1559，优化在多个资源约束下填充区块会变成一个复杂的 [多维背包问题](https://en.wikipedia.org/wiki/List_of_knapsack_problems)。使用 EIP-1559，绝大多数区块在任何资源上都不满容量，因此“接受任何支付足够费用的交易”的简单算法即可满足需求。\r\n\r\n目前我们为执行和 blob 具有多维 gas；原则上，我们可以将其增加到更多维度：**calldata**、**状态读取/写入**和 **状态大小扩展**。\r\n\r\n[EIP-7706](https://eips.ethereum.org/EIPS/eip-7706) 引入了一种针对 calldata 的新 gas 维度。同时，简化了多维 gas 机制，使所有三种类型的 gas 落入一个（EIP-4844 风格）框架，从而解决 EIP-1559 的数学缺陷。\r\n\r\n[EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) 是一个更为精准的解决方案，旨在解决平均情况与最坏情况资源问题，更严格地限制最大 calldata，而不引入全新的维度。\r\n\r\n进一步的方向是解决更新速率问题，并找到一个更快的 basefee 计算算法，同时保留 EIP-4844 机制所引入的关键不变量（即：从长远来看，平均使用接近 _准确地_ 目标）。\r\n\r\n#### 现有研究的一些链接有哪些？\r\n\r\n* EIP-1559 FAQ: [https://notes.ethereum.org/@vbuterin/eip-1559-faq](https://notes.ethereum.org/@vbuterin/eip-1559-faq)\r\n* 对 EIP-1559 的实证分析：\r\n* 允许快速调整的改进提案：\r\n* EIP-4844 FAQ，basefee 机制部分：[https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#How-does-the-exponential-EIP-1559-blob-fee-adjustment-mechanism-work](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#How-does-the-exponential-EIP-1559-blob-fee-adjustment-mechanism-work)\r\n* EIP-7706: \r\n* EIP-7623: \r\n* 多维 gas：\r\n\r\n#### 剩下的工作是什么，权衡是什么？\r\n\r\n多维 gas 有两个主要权衡：\r\n\r\n* 它增加了协议的复杂性\r\n* 它增加了填满区块到容量所需的最佳算法的复杂性\r\n\r\n对于 calldata，协议复杂性是一个相对较小的问题，但对于在“EVM 内部”的 gas 维度，如存储读取和写入则成为更大的问题。问题在于，不仅是用户设置 gas 限制：还有合约在调用其他合约时也设置限制。而今天，它们设置限制的唯一方法是单维。\r\n\r\n解决此问题的一个简单方法是仅在 EOF 内部提供多维 gas，因为 EOF 不允许合约在调用其他合约时设置 gas 限制。非 EOF 合约在进行存储操作时必须在所有类型的 gas 中支付费用（例如，如果 `SLOAD` 的成本占用一个区块的存储访问 gas 限制的 0.03%，非 EOF 用户也将被收取 0.03% 的执行 gas 限制的费用）。\r\n\r\n对多维 gas 进行更深入的研究将有助于了解权衡并找出理想的平衡。\r\n\r\n#### 它是如何与路线图的其他部分相互作用的？\r\n\r\n成功实施的多维 gas 可以大大减少某些“最坏情况”资源使用，因此减少对优化性能的需求，以支持例如 STARKed 基于哈希的二叉树。对状态大小增长的硬性目标将使客户端开发者更容易规划和估算未来的需求。\r\n\r\n如上所述，EOF 使得实现更极端版本的多维 gas 变得显著容易，因为它具有 gas 不可观察的特性。\r\n\r\n可验证延迟函数（VDFs）\r\n\r\n它解决了什么问题？\r\n\r\n今天，以太坊使用 [RANDAO 基于随机数](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#aside-randao-seeds-and-committee-generation) 来选择提议者。RANDAO 基于随机数的工作方式是要求每个提议者揭示他们提前承诺的秘密，并将每个揭示的秘密混合到随机数中。每个提议者因此有“1 位操控”：他们可以通过不出席来改变随机性（要付出代价）。这在寻找提议者时是相当可接受的，因为你很少能通过放弃一个会议来获得两个新的提议机会。但对于需要随机性的链上应用来说这并不可行。理想情况下，我们希望找到更可靠的随机性来源。\r\n\r\n#### 它是什么，如何运作？\r\n\r\n[可验证延迟函数](https://eprint.iacr.org/2018/601.pdf) 是一种只能顺序计算的函数，无法通过并行化加速。一个简单的例子是重复哈希：计算 `for i in range(10**9): x = hash(x)`。输出，在 SNARK 证明正确性的证明下，可以用作随机值。其理念是输入根据 T 时刻可用的信息进行选择，并且在 T 时刻输出尚未知晓：它在 T 后某个时间可用，一旦有人完全运行计算。由于任何人都可以运行计算，因此没有可能抑制结果，也就无法操控结果。\r\n\r\n可验证延迟函数的主要风险是**意外优化**：有人发现了如何以比预期快得多的速度运行该函数，从而允许他们基于未来输出操控他们在 T 时刻露出的信息。意外优化可以通过两种方式发生：\r\n\r\n* **硬件加速**：有人制造了可以比现有硬件更快地运行计算循环的 ASIC。\r\n* **意外并行化**：有人找到一种方法，通过并行处理更快地运行函数，即使这样做需要 100 倍的资源。\r\n\r\n设计成功的 VDF 的任务是避免这两个问题，同时保持效率实用（例如，基于哈希方法的一个问题是实时进行哈希的 SNARK 证明有很大的硬件要求）。硬件加速通常可以通过有一个公共卫生模型行为主体自行创建和分发合理接近最优的 VDF ASIC 来解决。\r\n\r\n#### 现有研究的一些链接有哪些？\r\n\r\n* vdfresearch.org: \r\n* 针对用于以太坊的 VDFs 攻击的思考，2018 年：\r\n* 针对提议的 VDF MinRoot 的攻击：\r\n\r\n#### 剩下的工作是什么，权衡是什么？\r\n\r\n目前没有一种 VDF 结构能在所有方面满足以太坊研究人员的要求。我们还有更多工作需要找到这样的函数。如果我们拥有它，主要的权衡则是是否将其纳入：功能与协议复杂性和安全风险的简单权衡。如果我们认为 VDF 是安全的，但最终却不安全，则根据其实施方式，安全性下降到 RANDAO 假设（每个攻击者 1 位操控）或稍微更糟的状态。因此，即使一个损坏的 VDF 也不会破坏协议，尽管它会破坏应用或依赖于其的任何新协议功能。\r\n\r\n#### 它是如何与路线图的其他部分相互作用的？\r\n\r\nVDF 是以太坊协议相对独立的成分，虽然除了增强提议者选择的安全性外，它在 (i) 依赖随机性链上应用和可能 (ii) 加密的 mempool 中也有用途，尽管基于 VDF 制作加密 mempool 仍需依赖尚未到来的其他密码学发现。\r\n\r\n需要牢记的一点是，考虑到硬件的不确定性，VDF 输出生成和其被需要之间将存在一些“松弛”。这意味着信息将在几个区块之前可获得。这可能是一个可以接受的成本，但在如单槽确定性或委员会选择设计中应加以考虑。\r\n\r\n模糊化和一次性签名：密码学的远期未来它解决了什么问题？\r\n\r\nNick Szabo 最著名的文章之一是其 1997 年的关于“[神协议](https://nakamotoinstitute.org/library/the-god-protocols/)”的论文。在这篇文章中，他指出，许多多方应用往往依赖于一个“受信任的第三方”来管理互动。在他看来，密码学的作用是创建一个模拟的受信任第三方，完成同样的工作，而不实际要求对任何特定角色的信任。\r\n\r\n\r\n\r\n到目前为止，我们只能部分接近这一理想。如果我们所需的仅是一个 _透明_ 的虚拟计算机，其中数据和计算无法被关闭、审查或篡改，但隐私不是目标的话，那么区块链可以做到这一点，尽管可扩展性有限。如果隐私 _是_ 一个目标，那么直到最近，我们只能为一些特定的应用创作一些特定的协议：基本身份验证的数字签名、[环签名](https://en.wikipedia.org/wiki/Ring_signature) 和 [可链接环签名](https://www.sciencedirect.com/science/article/abs/pii/S1383762122002715) 的原始匿名形式、[基于身份的加密](https://en.wikipedia.org/wiki/Identity-based_encryption) 以在对受信任的发放者的特定假设下实现更便捷的加密、[盲签名](https://en.wikipedia.org/wiki/Blind_signature) 用于 [Chaumian 电子现金](https://en.wikipedia.org/wiki/Ecash) 等等。这种方法为每个新应用都需要大量工作。\r\n\r\n在 2010 年代，我们首次看到了一种基于 [可编程密码学](https://learnblockchain.cn/article/9015) 的不同且更强大的方法的初步风貌。与每创建一个新应用就采用新协议相比，我们可以使用强大的新协议——特别是 **ZK-SNARKs**——为 _任意程序_ 添加密码学保证。ZK-SNARKs 允许用户证明他们持有的数据的 _任何任意声明_，以一种证明 (i) 易于验证且 (ii) 不泄漏除声明本身外的任何数据的方式。这是隐私与可扩展性的巨大进步，我将其比作 **[变换器](https://en.wikipedia.org/wiki/Transformer_\\(deep_learning_architecture\\))** 在 AI 中的效应。数千人年的特定于应用的工作突然被可以轻松插入以解决意想不到的广泛问题的通用解决方案所淹没。\r\n\r\n但 ZK-SNARKs 只是这三种相似的极其强大的技术原语中的第一种。这些协议非常强大，以至于当我想到它们时，它们令我想起了一组在儿童时期游玩和观看的游戏和电视节目中的极其强大牌组： [埃及神卡](https://yugioh.fandom.com/wiki/Egyptian_God)。埃及神卡是一组三张极其强大的牌，传说其制造可能致命，且如此强大，以至于在决斗中无法使用。同样，在密码学中，我们也有这组埃及神协议：\r\n\r\n\r\n\r\n#### 它是什么，如何运作？\r\n\r\n**ZK-SNARKs** 是这三种协议之一，[我们已经实现](https://learnblockchain.cn/article/10962) 到较高的成熟度。在过去五年中，在证明器速度和开发者友好性上的大幅改进，使得 ZK-SNARKs 成为以太坊可扩展性和 [隐私](https://learnblockchain.cn/article/11478) 战略的基石。但 ZK-SNARKs 有一个重要的限制：你需要知道数据才能对其做出证明。ZK-SNARK 应用中的每个状态项目必须有单一的“所有者”，这位所有者必须在场以批准对它的任何读取或写入。\r\n\r\n第二种没有此限制的协议是 [**全同态加密**](https://learnblockchain.cn/article/11603) **（FHE）**。FHE 允许你 **对加密数据进行任何计算，而无需查看数据**。这使你能够 为用户的利益对其数据进行计算，同时保持数据和算法的私密性。它还让你能将投票系统 [比如 MACI](https://maci.pse.dev/) 扩展到几乎完美的安全和隐私保证。长期以来，FHE 被认为在实际应用中太低效，但现在它终于变得足够高效，我们开始看到应用。\r\n\r\n\r\n\r\n但 FHE 同样有其限制：任何基于 FHE 的技术仍需要 _某人_ 持有解密密钥。这可以是一个 M-of-N 的分布式设置，甚至可以使用 TEE 添加第二层防御，但这仍然是一个限制。\r\n\r\n这就引出了第三种协议，它比前两者加在一起更强大：[**不可区分模糊化**](https://en.wikipedia.org/wiki/Indistinguishability_obfuscation)**。** 虽然离成熟还有 _很远_，但截至 2020 年，我们在基于标准安全假设的理论上证明的协议，最近也开始侧重于实现 [GitHub 上的实现](https://github.com/SoraSuegami/iOMaker/tree/main)。不可区分模糊化让你 **创建一个“加密程序”，以隐蔽的方式执行任意计算，所有程序的内部细节都被隐藏**。作为简单的例子，你可以把一个私钥放入一个模糊化的程序中，该程序只能让你用它来签署素数，然后将这个程序分发给其他人。他们可以用这个程序签署任意素数，但无法取出密钥。但它的威力远不止于此：配合哈希，它可用于实现其他任何密码学原语，以及更多。\r\n\r\n模糊化程序唯一无法做到的事情，就是防止被复制。但在这方面，未来还有比这更强大的东西，尽管它可能需要每个人都拥有量子计算机：[量子一次性签名](https://eprint.iacr.org/2020/107.pdf)。\r\n\r\n\r\n\r\n通过模糊化和一次性签名，我们几乎可以构建完美的无信任第三方。唯一我们无法仅靠密码学做到的工作，仍需要区块链来确保其抗审查性。这些技术将使我们不仅能使以太坊本身更加安全，而且也能在其上构建更强大的应用。\r\n\r\n为了了解这些原语如何增添力量，让我们看一个关键的例子： **投票**。投票是一个引人入胜的问题，因为它需要满足许多棘手的安全特性，包括极强的可验证性和隐私性的形式。尽管具有强安全性特性的投票协议已经存在几十年，但通过推动应用创新，我们可以为任意投票协议设计（例如： [二次投票](https://learnblockchain.cn/article/11480)、[成对边界的二次资金](https://ethresear.ch/t/pairwise-coordination-subsidies-a-new-quadratic-funding-design/5553) 、[簇匹配的二次资金](https://www.gitcoin.co/blog/wtf-is-cluster-matching-qf) 等）提出更具挑战性的问题。那是说，我们希望“计票”步骤成为一个任意程序。* 首先，假设我们将票数公开记录在 **区块链** 上。这为我们带来了 **公共可验证性** （任何人都可以验证最终结果是否正确，包括计票规则和资格规则）和 **抗审查性** （无法阻止人们投票）。但是我们没有隐私。\r\n * 然后，我们增加了 **ZK-SNARKs**。现在，我们拥有了 **隐私**：每个票数都是匿名的，同时确保只有授权选民可以投票，并且每位选民只能投票一次。\r\n * 接下来，我们加入了 [MACI机制](https://maci.pse.dev/)。投票被加密到一个中央服务器的解密密钥。中央服务器负责运行计票过程，包括抛弃重复的投票，并发布一个 ZK-SNARK 来证明结果。这保留了之前的保证（即使服务器在作弊！），但如果服务器是诚实的，它还增加了 **抗强迫性** 的保证：用户无法证明他们是如何投票的，即使他们想这样做。这是因为虽然用户可以证明他们的投票，但他们无法证明他们没有进行另一票以抵消其效果。这防止了贿赂和其他攻击。\r\n * 我们在 **FHE** 中运行计票，然后进行 N/2-of-N [阈值解密](https://en.wikipedia.org/wiki/Threshold_cryptosystem)计算。这样就形成了 **抗强迫性保证** [**N/2-of-N，而不是 1-of-1**](https://learnblockchain.cn/article/10953)。\r\n * 我们使计票程序 **混淆**，并设计混淆程序，使其在获得权限后才能给出输出，不论是通过区块链共识的证明，还是通过某种数量的工作证明，或两者都有。这 **几乎使抗强迫性保证变得完美**：在区块链共识的情况下，你需要 51% 的验证者共同破坏它，而在工作证明的情况下，即使所有人勾结，重新运行计票以不同的选民子集尝试提取单个选民的行为，也是极其昂贵的。我们甚至可以让程序对最终计票做出小的随机调整，以使提取单个选民的行为变得更加困难。\r\n * 我们添加了 **一次性签名**，这是一种依赖于量子计算的原语，允许签名只能用于一次特定类型的消息。这 **使抗强迫性保证确实完美**。\r\n\r\n不可区分的混淆还允许其他强大的应用。例如：\r\n\r\n * **DAO、链上拍卖和其他具有任意内部秘密状态的应用**。\r\n * **一个真正的通用[可信设置](https://learnblockchain.cn/article/10979)**：某人可以创建一个包含密钥的混淆程序，并可以运行任何程序并提供输出，将 `hash(key, program)` 作为程序的输入。给予这样的程序，任何人也可以将程序放入自身，将程序的预存在密钥与他们自己的密钥结合，从而扩展设置。这可以用来为任何协议生成一个 1-of-N 可信设置。\r\n * **验证仅为签名的 ZK-SNARKs**。实现这一点很简单：拥有一个可信设置，其中有人创建一个混淆程序，该程序仅在是有效 ZK-SNARK 时才用密钥对消息进行签名。\r\n * **加密的内存池**。使交易以一种方式加密变得微不足道，即只有在未来出现某些链上事件时才会被解密。这甚至可以包括 VDF 的成功执行。\r\n\r\n通过一次性签名，我们可以使区块链免受导致最终性的 51% 攻击，尽管审查攻击依然可能。类似于一次性签名的原语能够实现 [量子货币](https://en.wikipedia.org/wiki/Quantum_money)，解决不需要区块链的双重支付问题，尽管许多更复杂的应用仍然需要链。\r\n\r\n如果这些原语能够变得足够高效，那么世界上的大多数应用程序都可以去中心化。主要瓶颈将是验证实现的正确性。\r\n\r\n#### 现有研究的一些链接是什么？\r\n\r\n * 2021年不可区分混淆协议： \r\n * 混淆如何帮助以太坊： \r\n * 首个已知的一次性签名构造： \r\n * 混淆尝试实现 (1)： \r\n * 混淆尝试实现 (2)： \r\n\r\n#### 还有什么需要做的，权衡是什么？\r\n\r\n**还有很多事情要做。** 不可区分混淆极其不成熟，候选构造的速度慢得无法在应用中使用（如果不是更多的话）。不可区分混淆以“理论上”多项式时间的运行时间而闻名，但在实践中运行时间可能长于宇宙的寿命。最近的协议已经降低了运行时间的极端性，但开销对于常规使用仍然过高：一位实施者预期达到一年的运行时间。\r\n\r\n量子计算机甚至还不存在：你今天在互联网上看到的所有构造都要么是不能执行超过 4 位的任意计算的原型，要么不是真正的量子计算机，尽管它们可能有量子组件，但仍无法运行实际有意义的计算，比如 [Shor 算法](https://en.wikipedia.org/wiki/Shor%27s_algorithm)或 [Grover 算法](https://en.wikipedia.org/wiki/Grover%27s_algorithm)。最近，有迹象表明“真正的”量子计算机 [离我们不再遥远](https://scottaaronson.blog/?p=8329)。然而，即便“真正的”量子计算机很快出现，普通人在他们的笔记本电脑或手机上拥有量子计算机的那一天，也可能是在强大的机构获得能够破解椭圆曲线密码学的量子计算机许多年后。\r\n\r\n对于不可区分混淆，一个关键的权衡是安全假设。有更激进的设计 [使用](https://software.imdea.org/events/invited-talks/2024/02-27/) 异常的 [假设](https://eprint.iacr.org/2015/1062.pdf)。这些通常具有更现实的运行时间，但异常假设有时会 [被打破](https://eprint.iacr.org/2014/906.pdf)。随着时间的推移，我们可能会理解足够的格论，使得不被打破的假设。然而，这条路径更具风险。更保守的路径是坚持使协议的安全性显著降低至“标准”假设，但这可能意味着在我们获得足够快速的运行协议之前需要更长的时间。\r\n\r\n#### 它与路线图的其他部分如何互动？\r\n\r\n极其强大的密码学可能彻底改变游戏。例如：\r\n\r\n * 如果我们获得 ZK-SNARKs，其验证与签名一样便捷，那么我们可能不再需要任何聚合协议；我们只需在链上直接验证。\r\n * 一次性签名可能意味着更安全的权益证明协议。\r\n * 许多复杂的隐私协议可以被“仅仅”拥有隐私保护的 EVM 所取代。\r\n * 加密的内存池变得更易于实现。\r\n\r\n最初，利益将会出现在应用层，因为以太坊 L1 本质上需要对安全假设持保守态度。然而，单独的应用层使用就可能会改变游戏，就如 ZK-SNARKs 的出现一样。\r\n\r\n>- 原文链接： [vitalik.eth.limo/general...](https://vitalik.eth.limo/general/2024/10/29/futures6.html)\r\n>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～"},"author":{"user":"https://learnblockchain.cn/people/71","address":null},"history":"bafkreiarxj5ua2uqtijetbcbe2bs5xkz6eip7ik2npawfnars3sasi6gei","timestamp":1741138633,"version":1}