计划深入优化以太坊协议，旨在提升网络效率与可持续性。它不仅可能突破技术瓶颈，更有望革新区块链安全与隐私。
原文：Possible futures of the Ethereum protocol, part 6: The Splurge（vitalik.eth）
作者：vitalik.eth
编译：Yewlne，LXDAO
封面：Galaxy
译者前言
在区块链技术飞速发展的今天，系统架构的复杂度也在逐渐提升，给开发者和用户都带来了新的挑战。“The Splurge” 计划强调通过优化和完善现有协议细节，来提升网络的效率和可持续性。这些前沿技术的探索，不仅有望解决当前的技术瓶颈，还可能彻底改变区块链的安全和隐私机制，使之更接近于 “无信任” 的理想状态。希望这次翻译能够帮助更多的中文读者了解以太坊协议的最新进展，激发大家对这些重要但常被忽视的主题的兴趣。
本文概述
本文共约 10,000 字，有 5 个部分，阅读完本文预计需要 55 分钟。
- EVM 改进
- 账户抽象
- EIP-1559 改进
- 可验证延迟函数（VDFs）
- 混淆和一次性签名：密码学的未来
正文内容
《以太坊协议可能的未来（六）：The Splurge》
特别鸣谢 Justin Drake 和 Tim Beiko 的反馈与评审。
有些东西很难归入单一类别。以太坊协议设计中存在许多 “小细节”，它们对以太坊的成功至关重要，但难以妥善归类到更大的子类别中。在实践中，其中约一半内容涉及各种形式的 EVM 改进，其余则包含各种细分主题。这就是 "Splurge" 升级的目标所在。
The Splurge：关键目标
- 将 EVM 引导至高性能且稳定的 “终局状态”。
- 将账户抽象引入协议层，让所有用户都能受益于更安全、更便捷的账户。
- 优化交易费用经济模型，在提升可扩展性的同时降低风险。
- 探索先进的密码学技术，从长远来看可以使以太坊变得更好。
本章内容：
- EVM 改进
- 账户抽象
- EIP-1559 改进
- 可验证延迟函数（VDFs）
- 混淆和一次性签名：密码学的未来
EVM 改进
它解决什么问题？
目前的 EVM 难以进行静态分析，这使得实现高效部署、进行代码形式化验证以及后续扩展变得困难。另外，由于其效率很低，除非通过预编译明确支持，否则很难实现多种高级密码学运算。
它是什么，它是如何工作的？
当前的 EVM 改进路线图中，首要步骤就是计划在下次硬分叉中引入的 EVM 对象格式（EOF）。EOF 包含了一系列 EIP 提案，这些提案为 EVM 定义了一个新版本的代码格式，具有以下几个关键特性：
- 实现了代码（可执行但无法从 EVM 中读取）与数据（可读取但不可执行）的分离
- 禁用动态跳转机制，仅保留静态跳转
- EVM 代码将无法获取 gas 相关信息
- 新增了显式的子程序调用机制
老版本的合约将可以继续使用且允许创建，不过未来可能会逐步淘汰旧版合约 (甚至可能强制将它们转换为 EOF 格式)。新版本的合约则可以享受 EOF 带来的效率提升：一方面可以通过子程序特性略微减小字节码体积，另一方面也能从 EOF 独有的新特性和更低的 gas 消耗中获益。
EOF 引入后，使得后续升级变得更加容易。目前发展最成熟的是 EVM 模块化算术扩展 (EVM-MAX)。EVM-MAX 专门为模运算设计了一组新的运算操作，并将它们放在一个新的内存空间中，其他指令无法访问该空间。这使得系统可以采用一些优化算法，比如蒙哥马利乘法。
一个较新的构思是将 EVM-MAX 与单指令多数据（SIMD）特性结合起来。SIMD 这个想法在以太坊社区已经存在很长时间了，最早可以追溯到 Greg Colvin 提出的 EIP-616。SIMD 可用于加快各类密码学计算，包括哈希函数、基于 32 位的各种 STARK 证明（32-bit STARKs）和格密码学（lattice-based cryptography）。EVM-MAX 结合 SIMD 这两项扩展能很好地满足 EVM 在性能方面的提升需求。
这个组合 EIP 的初步设计将以 EIP-6690 为基础，并作如下扩展：
- 支持以下类型的模数：（i）任意奇数，或（ii）2 的 768 次方及以下的 2 的幂。
- 为每个 EVMMAX 指令（add、sub、mul）增加新版本。这个版本不是接收 3 个即时变量 x、y、z，而是接收 7 个即时变量：x_start、x_skip、y_start、y_skip、z_start、z_skip、count。
用 Python 代码表示，这些指令的功能等同于：
for i in range(count):
mem[z_start + z_skip * count] = op( mem[x_start + x_skip * count], mem[y_start + y_skip * count] )
除非在实际实施中，它将被并行处理。
- 针对模数为 2 的幂的情况，将计划添加 XOR、AND、OR、NOT 和 SHIFT（支持循环和非循环）等运算指令。此外还会添加 ISZERO 指令，用于将运算结果推送到 EVM 主栈。
这些功能足以支持实现椭圆曲线密码学、小域密码学（如 Poseidon、circle STARKs）、传统哈希函数（如 SHA256、KECCAK、BLAKE）以及格密码学（Lattice-based cryptography）。
其他 EVM 升级方案也有可能，但目前关注度还不高。
与现在研究有什么联系？
- EOF: https://evmobjectformat.org/
- EVM-MAX: https://eips.ethereum.org/EIPS/eip-6690
- SIMD: https://eips.ethereum.org/EIPS/eip-616
还有什么要做，以及需要权衡什么？
目前计划在下一次硬分叉中引入 EOF。尽管移除该功能仍有可能——此前也发生过在硬分叉前最后一刻移除特性的情况——但这将面临诸多阻力。如果移除 EOF，意味着后续所有 EVM 升级都需要在不具备 EOF 的情况下进行，这虽然可行但会带来更多技术挑战。
EVM 的主要取舍在于 L1 复杂度与基础架构复杂度之间的平衡。EOF 将会给 EVM 实现增加显著数量的代码，且静态代码检查也非常复杂。作为回报，我们能获得高级语言的简化、EVM 实现的简化以及其他收益。可以说，任何优先考虑以太坊 L1 持续改进的路线图都应该包含 EOF 并以此为基础。
其中一项重要的工作是实现类似于 EVM-MAX 结合 SIMD 这样的功能，并对各种密码学操作进行 gas 消耗的基准测试。
它与路线图的其他部分如何互动？
L1 对 EVM 的调整能够促进 L2 作出相应改变。如果其中一层单独调整而另一层不变，就会引发一些兼容性问题，这会带来其他负面影响。此外，EVM-MAX 结合 SIMD 功能可以降低多种证明系统的 gas 成本，从而提升 L2 层的执行效率。这也便于移除更多预编译模块，因为可以用 EVM 代码替代这些模块，且基本不会对效率造成大的影响。
账户抽象
解决了什么问题？
目前，交易仅支持一种验证方式：ECDSA 签名。最初，账户抽象旨在突破这一限制，使账户验证逻辑可以使用任意 EVM 代码实现。这将能够支持多种应用场景：
- 迁移至抗量子密码学
- 轮换旧密钥（这是普遍认可的安全实践）
- 多签钱包和社交恢复钱包。
- 对低价值操作使用单一密钥，对高价值操作使用其他密钥（或密钥组）
- 实现无中继器的隐私协议，显著降低系统复杂度并消除核心依赖点
自 2015 年账户抽象概念提出以来，其目标范围已经扩大，增加了许多 “便利性目标”，例如允许一个没有 ETH 但持有特定 ERC20 代币的账户直接使用该 ERC20 代币支付 gas 费用。下图总结了这些目标：
这里的 MPC 指的是多方计算（multi-party computation）：这是一种已有 40 年历史的技术，它将密钥分片存储到多个设备中，并通过密码学方法在不直接合并密钥分片的情况下生成签名。
EIP-7702 是计划在下一次硬分叉中引入的提案。EIP-7702 的出现源于人们越来越认识到，有必要为所有用户（包括 EOA 用户）提供账户抽象的便利功能，以在短期内改善所有人的用户体验，并避免生态系统分裂为两个独立的系统。这项工作始于 EIP-3074，最终形成了 EIP-7702。EIP-7702 使账户抽象的 “便利功能” 立即可供所有用户使用，包括 EOA（外部拥有账户，即由 ECDSA 签名控制的账户）。
从图表中可以看出，虽然某些挑战（特别是 “便利性” 方面的挑战可以通过多方计算协议或 EIP-7702 等渐进式技术来解决，但推动最初账户抽象提案的大部分安全目标，只能通过回归并解决最初的问题来实现：即允许智能合约代码直接控制交易验证过程。然而，至今尚未实现这一点的原因是，要安全地实现这一功能本身就是一项挑战。
这是什么，它是如何工作的?
从本质上说，账户抽象的核心很简单：允许智能合约，而不仅仅是外部拥有账户（EOA），来发起交易。所有的复杂性都源于如何以一种既有助于维护去中心化网络，又能防范拒绝服务（DoS）攻击的方式来实现这一点。
一个能够阐明这一关键挑战的典型例子是多重无效化问题（Multi-invalidation Problem）：
如果有 1000 个账户的验证函数都依赖于某个共享的值 S，并且在当前 S 值下，内存池中存在许多有效的交易，那么一笔改变 S 值的交易可能会使内存池中的所有其他交易失效。这使得攻击者可以以极低的成本向内存池发送垃圾交易，占用网络节点的资源。
多年来，为了在扩展功能的同时限制拒绝服务（DoS）攻击的风险，人们付出了大量的努力，最终，有一种解决方案使大家就如何实现 “理想的账户抽象” 达成了共识：ERC-4337。
ERC-4337 的工作原理是将用户操作的处理分为两个阶段：验证和执行。首先处理所有的验证，然后再处理所有的执行。在内存池中，只有当用户操作的验证阶段仅涉及其自身账户，且不读取环境变量时，该操作才会被接受。这可以防止多重无效化攻击。同时，对验证步骤也设定了严格的 gas 限制。
ERC-4337 最初被设计为一个协议外的标准（ERC），这是因为当时以太坊客户端开发人员正专注于升级 “The Merge” 工作，没有多余的精力开发其他功能。这就是为什么 ERC-4337 使用了名为用户操作（User Operations）的自定义对象，而不是常规交易。然而，最近我们意识到，有必要将其部分内容纳入协议中。主要有两个原因：
- EntryPoint 作为合约所固有的效率低下问题：每个捆绑操作需要额外约 10 万 gas，每个用户操作还需要额外数千 gas。
- 需要确保以太坊的特性，例如由包含列表（inclusion lists）提供的包含保证，能够适用于账户抽象用户。
此外，ERC-4337 还扩展了两个功能：
- 支付主体（Paymasters）：该功能允许一个账户代表另一个账户支付费用。这违反了验证阶段只能访问发送账户自身的规则，因此引入了特殊处理机制来支持支付主体机制并确保其安全性。
- 聚合器（Aggregators）：该功能支持签名聚合，例如 BLS 聚合或基于 SNARK 的聚合。这对于在 Rollups 上实现最高水平的数据效率是必不可少的。
有哪些现有的研究资料？
- 账户抽象历史演进的演讲：https://www.youtube.com/watch?v=iLf8qpOmxQc
- ERC-4337：https://eips.ethereum.org/EIPS/eip-4337
- EIP-7702：https://eips.ethereum.org/EIPS/eip-7702
- BLSWallet 代码（聚合功能）：https://github.com/getwax/bls-wallet
- EIP-7562（写入协议的账户抽象）：https://eips.ethereum.org/EIPS/eip-7562
- EIP-7701（基于 EOF 的写入协议账户抽象）：https://eips.ethereum.org/EIPS/eip-7701
还有什么需要做，以及有哪些权衡？
剩余的主要问题是确定如何将账户抽象化完全纳入协议中。最近一个备受关注的账户抽象写入协议的提案是 EIP-7701，它在 EOF 的基础上实现了账户抽象。账户可以拥有一个独立的验证代码段，如果账户设置了对应代码段，那么在该账户发起的交易的验证步骤中就会执行该代码。
有趣的是，这种方法清晰地展现了两种等价的原生账户抽象实现方式：
- 将 EIP-4337 纳入协议中
- 一种新型的 EOA，其签名算法由 EVM 代码执行
如果我们一开始就对验证过程中可执行代码的复杂性设置严格限制——不允许访问外部状态，甚至最初设置的 gas 限制低到无法用于抗量子或隐私保护应用——那么这种方法的安全性就非常明确：它只是用耗时相近的 EVM 代码执行替代 ECDSA 验证。然而，随着时间的推移，我们需要放宽这些限制，因为允许隐私保护应用无需中继器即可运行，以及实现抗量子能力，都非常重要。为此，我们确实需要找到更灵活的方式来应对拒绝服务（DoS）风险，而不是要求验证步骤极度简化。
主要的权衡似乎在于：是更早地将一个较少人满意的方案写入协议，还是等待更长时间，可能获得一个更理想的解决方案。理想的方法可能是某种混合方案。一种混合方案是更快地将某些用例纳入协议，留出更多时间来解决其他问题。另一种方法是先在 L2 上率先部署更激进的账户抽象版本。然而，这面临的挑战是，要让 L2 团队愿意采纳一个提案，他们需要确信 L1 和其他 L2 日后会采用兼容的方案。
另一个我们需要明确考虑的应用是密钥库账户，它在 L1 或专用的 L2 上存储账户相关状态，但可以在 L1 和任何兼容的 L2 上使用。要有效地实现这一点，可能需要 L2 支持 L1SLOAD 或 REMOTESTATICCALL 等指令，不过这也要求 L2 上的账户抽象实现能够支持它。
它如何与路线图的其他部分互动？
包含列表（Inclusion Lists）需要支持账户抽象交易。实际上，包含列表和去中心化内存池的需求最终非常相似，尽管包含列表有更多的灵活性。此外，理想情况下，L1 和 L2 上的账户抽象实现应尽可能保持一致。如果我们预计未来大多数用户将使用 keystore Rollups，账户抽象设计就应该考虑到这一点。
EIP-1559 改进
它解决了什么问题？
EIP-1559 于 2021 年在以太坊上实施，显著改善了平均区块包含时间。
然而，目前 EIP-1559 的实现存在几个不完善之处：
- 公式略有缺陷：它的目标是填满约 50-53% 的区块（取决于方差），而不是 50%（这与数学家所说的 “算术-几何均值不等式” 有关）
- 在极端情况下，调整速度不够快。
后来用于数据块（blobs）的公式（EIP-4844）在设计时就明确考虑了解决第一个问题，整体上也更加简洁。无论是 EIP-1559 本身还是 EIP-4844，都没有尝试解决第二个问题。因此，当前的状况是一个令人困惑的过渡状态，涉及两种不同的机制，甚至有理由认为，随着时间的推移，这两种机制都需要改进。
此外，以太坊的资源定价还存在其他一些区别于 EIP-1559 的弱点，但可以通过调整 EIP-1559 来解决这些问题。其中一个主要问题是平均情况与最坏情况之间的差异：以太坊的资源价格必须设定为能够处理最坏情况（即一个区块的所有 gas 消耗会占用一个资源），但平均使用量远低于此，这导致了效率低下。
它是什么，它是如何工作的?
解决这些效率低下问题的方案是多维 Gas：为不同的资源设置独立的价格和限制。从技术上讲，这一概念独立于 EIP-1559，但 EIP-1559 使其更易于实现：在没有 EIP-1559 的情况下，面对多种资源约束，最优地打包区块是一个复杂的多维背包问题（multidimensional knapsack problem）。而有了 EIP-1559，大多数区块在任何资源上都未达到满负荷，因此简单的 “接受任何支付足够费用的交易” 算法即可满足需求。
我们现在已经有了执行和数据块（blobs）的多维 gas；原则上，我们可以增加更多维度：调用数据（calldata）、状态读写和状态大小扩展。
EIP-7706 为 calldata 引入了一个新的 gas 维度。同时，它通过使三种类型的 gas 都遵循一个（EIP-4844 风格的）框架来简化多维 gas 机制，从而也解决了 EIP-1559 的数学缺陷。
EIP-7623 是一个更为精细的解决方案，用于应对平均情况与最坏情况的资源问题。它在不引入全新维度的情况下，更严格地限定了最大调用数据（calldata）。
更进一步的方向是解决更新速率问题，找到一个更快速的基础费用（base fee）算法，同时保持 EIP-4844 机制引入的关键不变量（即：从长远来看，平均使用量会更精确地接近目标值）。
有哪些现有的研究资料？
- EIP-1559 常见问题解答：https://notes.ethereum.org/@vbuterin/eip-1559-faq
- EIP-1559 实证分析：https://dl.acm.org/doi/10.1145/3548606.3559341
- 关于快速调整的改进提案：https://kclpure.kcl.ac.uk/ws/portalfiles/portal/180741021/Transaction_Fees_on_a_Honeymoon_Ethereums_EIP_1559_One_Month_Later.pdf
- EIP-4844 常见问题解答，基础费用机制部分：https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#How-does-the-exponential-EIP-1559-blob-fee-adjustment-mechanism-work
- EIP-7706：https://eips.ethereum.org/EIPS/eip-7706
- EIP-7623：https://eips.ethereum.org/EIPS/eip-7623
- 多维 Gas：https://vitalik.eth.limo/general/2024/05/09/multidim.html
还有什么需要做，以及有哪些权衡？
多维 Gas 有两个主要的权衡：
- 增加了协议的复杂性
- 增加了填充区块容量所需的最优算法的复杂性
对于调用数据（calldata），协议复杂性是一个相对较小的问题，但对于位于 EVM 内部的 gas 维度（如存储读写）而言，这个问题就更为严重。问题在于，设置 gas 限制的不仅仅是用户：当合约调用其他合约时，它们也会设置限制。而目前，它们设置限制的方式仍是单一维度的。
消除这个问题的一个简单方法是仅在 EOF 内部提供多维 gas，因为 EOF 不允许合约在调用其他合约时设置 gas 限制。非 EOF 合约在进行存储操作时，必须为所有类型的 gas 支付费用（例如，如果一次 SLOAD 操作消耗了区块存储访问 gas 限制的 0.03%，那么非 EOF 用户也会被收取执行 gas 限制的 0.03%）。
对多维 Gas 进行更多的研究，将非常有助于理解这些权衡并找到理想的平衡点。
它如何与路线图的其他部分互动？
多维 Gas 的成功实现可以大幅减少某些 “最坏情况” 的资源使用，从而减轻为了支持例如基于 STARK 的哈希树而进行性能优化的压力。对状态大小增长设定明确的目标，可以使客户端开发者更容易规划和估计他们未来的需求。
如上所述，由于 EOF 具有 gas 不可观测性特征，它使得更高级版本的多维 Gas 更容易实现。
可验证延迟函数（VDFs）
它解决了什么问题？
目前，以太坊使用基于 RANDAO 的随机数来选择提议者。RANDAO 随机数的工作原理是要求每个提议者揭示他们预先承诺的秘密，并将揭示的每个秘密混合到随机数中。因此，每个提议者都有 “1 比特的操纵能力”：他们可以通过不出块（需要付出代价）来改变随机数。这对于选择提议者来说尚可接受，因为放弃一次机会以获得两次新的提议机会的情况非常罕见。但对于需要随机数的链上应用程序来说，这是不可接受的。理想情况下，我们需要找到一个更稳健的随机数来源。
它是什么, 它是如何工作的?
可验证延迟函数（VDF）是一种只能顺序计算、无法通过并行化加速的函数。一个简单的例子是重复哈希计算：执行 for i in range(10**9): x = hash(x)。输出结果，连同证明其正确性的 SNARK 证明，可以用作随机值。其思想是，输入基于在时间 T 可获得的信息选择，而输出在时间 T 时尚未知晓：只有当某人完全运行完计算后的一段时间后才可用。由于任何人都可以运行此计算，无法扣留结果，因此也就无法操纵结果。
可验证延迟函数的主要风险是意外优化：有人找到了一种比预期快得多的运行该函数的方法，使他们能够根据未来的输出，操纵他们在时间 T 时所揭示的信息。意外优化可能以两种方式发生：
- 硬件加速：有人制造了一种 ASIC，可以比现有硬件更快地运行计算循环。
- 意外并行化：有人找到了一种通过并行化更快运行该函数的方法，即使这样做需要消耗超过 100 倍的资源。
创建一个成功的 VDF 的任务在于避免上述两个问题，同时确效率足够实用（例如，基于哈希的方法存在一个问题，即实时对哈希进行 SNARK 证明需要极高的硬件要求）。硬件加速问题通常通过让公共物品参与者自行创建并分发接近最优的 VDF 专用 ASIC 来解决。
有哪些现有的研究资料？
- VDF 研究网站：https://vdfresearch.org/
- 关于针对以太坊中使用的 VDFs 攻击的思考，2018 年：https://ethresear.ch/t/verifiable-delay-functions-and-attacks/2365
- 针对 MinRoot（一个提议的 VDF）的攻击研究：https://inria.hal.science/hal-04320126/file/minrootanalysis2023.pdf
还有什么需要做，以及有哪些权衡？
目前，还没有一个在各方面都能完全满足以太坊研究人员要求的 VDF 构造。找到这样一个函数还需要更多的工作。如果我们有了这样的函数，主要的权衡就是是否将其纳入协议：这只是一个在功能性与协议复杂性和安全风险之间的简单取舍。如果我们认为一个 VDF 是安全的，但最终被证明是不安全的，那么根据其实现方式，安全性会降级到 RANDAO 假设（每个攻击者有 1 比特的操纵能力）或略差的程度。因此，即使 VDF 存在缺陷，也不会破坏协议本身，尽管它会破坏那些严重依赖它的应用程序或任何新的协议特性。
它如何与路线图的其他部分互动？
VDF 是以太坊协议中一个相对独立的组成部分，除了提高提议者选择的安全性外，它还可用于：（i）依赖随机数的链上应用程序，以及潜在的（ii）加密内存池。然而，基于 VDF 的加密内存池的实现仍然依赖于尚未实现的其他密码学突破。
需要注意的是，考虑到硬件的不确定性，VDF 输出的产生时间与其被需要的时间之间可能会有一些 “延迟”。这意味着信息可能会在提前几个区块时就被获取。这可能是一个可以接受的代价，但在设计诸如最终确定性或委员会选择机制时，应将其考虑在内。
混淆和一次性签名：密码学的未来
它解决了什么问题？
Nick Szabo 最著名的文章之一是 1997 年发表的一篇关于 “上帝协议” 的文章。在这篇文章中，他指出多方应用程序经常依赖于 “可信第三方” 来管理交互。在他看来，密码学的作用是创建一个模拟的可信第三方来完成相同的工作，而无需实际信任任何特定参与者。
到目前为止，我们只能部分地接近这个理想。如果我们只需要一个透明的虚拟计算机，其中数据和计算无法被关闭、审查或篡改，而隐私不是目标，那么区块链可以实现这一点，尽管其可扩展性有限。如果隐私确实是目标，那么直到最近，我们只能为特定应用创建一些专用协议：用于基本认证的数字签名、用于原始形式的匿名性的环签名和可链接环签名、在特定可信发行者假设下实现更便捷加密的基于身份的加密、用于 Chaumian 电子现金的盲签名等。这种方法需要为每个新应用投入大量工作。
在 2010 年代，我们首次看到了一种基于可编程密码学的全新且更强大的方法。我们无需为每个新应用开发专用协议，而是可以使用新型强大的协议——特别是 ZK-SNARKs，为任意程序添加密码学保证。ZK-SNARKs 让用户能够证明他们所持有数据的任意陈述，且这种证明（i）易于验证，（ii）除陈述本身外不会泄露任何数据。这在隐私性和可扩展性方面都取得了突破性进展，我将其比作人工智能领域中 Transformer 的影响力。数千年的人力投入到特定应用的工作中，突然被一个通用解决方案所替代，这个方案可以即插即用地解决大量意想不到的问题。
但 ZK-SNARKs 只是三大超级强大的通用型基础协议之一。这些协议如此强大，以至于当我想到它们时，它们让我想起了游戏王（Yu-Gi-Oh）。游戏王是我童年时期常玩的卡牌游戏和观看的动画片：埃及神卡。埃及神卡是三张极其强大的卡牌，传说它们的出现可能是致命的，而且它们太过强大以至于在决斗中被禁止使用。类似地，在密码学中，我们也有三个埃及神协议：
它是什么，它是如何工作的?
ZK-SNARKs 是这三大协议中已经发展得相当成熟的一个。在过去五年里，随着证明生成速度和开发友好度的显著提升，ZK-SNARKs 已成为以太坊在可扩展性和隐私性方面的基础技术。但 ZK-SNARKs 存在一个关键限制：必须掌握数据才能对其生成证明。ZK-SNARK 应用中，每个状态数据必须有唯一的 “所有者”，且任何读写操作都需要该所有者在场授权。
第二个协议克服了这一限制，它是全同态加密（Fully Homomorphic Encryption，FHE）。FHE 能够在不访问原始数据的情况下对加密数据执行任意计算。这使我们能够在保护数据和算法隐私的前提下，为用户处理其数据。它还能够增强 MACI 等投票系统，提供近乎完美的安全性和隐私性保证。FHE 曾长期被认为效率过低而难以实用，但如今其效率已达到实用水平，相关应用也开始涌现。
但 FHE 也存在局限：任何基于 FHE 的技术仍需要特定主体持有解密密钥。虽然可以采用 M-of-N 多方分储方案，甚至可以使用可信执行环境（TEE）作为第二重防护，但这仍是一个固有限制。
这引出了第三个协议，其威力超过前两者的总和：不可区分混淆（Indistinguishability Obfuscation）。尽管它距离实用化还非常遥远，但在 2020 年，我们已经基于标准安全假设建立了理论可行的协议，且近期已开始着手实现。不可区分混淆能够让你创建一个 “加密程序”，该程序可执行任意计算，同时完全隐藏其内部实现细节。举个简单例子，你可以将私钥封装进混淆程序中，使其仅能用于质数签名，然后将程序分发给他人。使用者可以用该程序对任意质数进行签名，但无法提取出私钥。但这仅是其能力的冰山一角：结合哈希函数，它可以实现任何其他密码学原语，并支持更多高级功能。
混淆程序唯一的限制在于无法防止程序本身被复制。不过，在这个领域已经出现了一项更强大的技术，只是它需要所有参与者都具备量子计算机：量子一次性签名（Quantum One-Shot Signatures）。
结合混淆技术和一次性签名，我们几乎可以构建完美的无信任第三方系统。唯一需要依赖区块链而无法仅通过密码学实现的，是抗审查能力。这些技术不仅能增强以太坊本身的安全性，还能支持构建更强大的上层应用。
为了解这些基础协议如何各自提升系统能力，让我们以一个典型案例来说明：投票系统。投票是一个极具挑战性的问题，因为它需要满足诸多复杂的安全属性，特别是在可验证性和隐私性方面都有极高要求。虽然强安全性的投票协议已存在数十年，但让我们设定更高的目标：设计一个能支持任意投票协议的系统，包括二次投票、配对约束二次方融资、群集匹配二次方融资等。换言之，我们期望 “计票” 环节能够支持任意程序逻辑。
- 首先，假设我们将投票数据记录在区块链上。这能实现公开验证（任何人都可以验证最终结果的正确性，包括计票规则和投票资格规则）和抗审查能力（无法阻止用户参与投票），但缺乏隐私保护。
- 然后，我们引入 ZK-SNARKs 技术。这实现了隐私保护：每票均为匿名，同时确保只有授权用户可以投票，且每个用户仅能投票一次。
- 接着，我们引入 MACI 机制。投票内容经加密后传输至中心服务器的解密密钥。中心服务器负责执行计票流程，包括过滤重复票项，并发布证明结果正确性的 ZK-SNARK。这不仅保持了前述保障（即使服务器作弊也不例外！），而且在服务器诚实的情况下，还提供了抗胁迫保护：用户无法证明自己的投票选择，即便他们主动想要证明。这是因为尽管用户可以证明某次投票行为，但无法证明自己没有投过过另一张票来抵消之前的投票。这有效防止了贿选和其他攻击行为。
- 我们在全同态加密（FHE）环境中执行计票，并通过 N/2-of-N 门限解密方案进行解密。这将抗胁迫保护机制从单点信任提升为 N/2 门限信任。
- 我们将计票程序进行代码混淆，并设计混淆程序使其只有在获得授权时才能输出结果，该授权可以是区块链共识证明、工作量证明或两者的组合。这使得抗胁迫保护机制达到近乎完美的程度：在区块链共识模式下，需要 51% 的验证节点串通才能破解；在工作量证明模式下，即便全网串通，通过运行不同用户子集的计票来还原单个用户的投票行为也会耗费巨大成本。我们还可以在最终统计结果中引入微小的随机扰动，进一步提高单个用户投票行为的隐匿性。
- 我们引入一次性签名机制，这是一种基于量子计算的基础协议，能确保签名仅可用于对特定类型消息进行一次性签署。这实现了完全的抗胁迫保护。
不可区分混淆还能支持其他强大的应用场景。例如：
- 支持任意内部加密状态的 DAO、链上拍卖及其他应用。
- 完全通用的可信设置：开发者可以创建一个包含密钥的混淆程序，该程序能执行任意程序并输出结果，将 hash(key, program) 作为输入参数。任何人获得此程序后，都能将程序嵌入自身，将程序原有密钥与自己的密钥合并，从而扩展初始化范围。这可用于为任意协议生成 1-of-N 的可信初始化。
- 仅需签名验证的 ZK-SNARKs。实现方式简单：通过可信初始化创建一个混淆程序，该程序仅在验证 ZK-SNARK 有效时才用密钥进行签名。。
- 加密交易内存池。它极大地简化了交易加密过程：交易仅在未来特定链上事件发生时才解密。这甚至可以包括 VDF（可验证延迟函数）的成功执行。
通过一次性签名机制，我们可以使区块链免受破坏最终性的 51% 攻击，但仍可能面临审查攻击。类似一次性签名的基础协议能够支持量子货币，无需依赖区块链就能解决双花问题，但更复杂的应用场景仍需要区块链支持。如果这些基础协议能达到足够的性能水平，世界上大多数应用都将具备去中心化的潜力。主要瓶颈在于如何验证实现的正确性。
有哪些现有的研究资料？
- 2021 年不可区分混淆协议研究：https://eprint.iacr.org/2021/1334.pdf
- 混淆技术如何增益以太坊：https://ethresear.ch/t/how-obfuscation-can-help-ethereum/7380
- 首个一次性签名构造方案：https://eprint.iacr.org/2020/107.pdf
- 混淆技术实现探索（1）：https://mediatum.ub.tum.de/doc/1246288/1246288.pdf
- 混淆技术实现探索（2）：https://github.com/SoraSuegami/iOMaker/tree/main
还有什么需要做，以及有哪些权衡？
仍面临诸多技术挑战。 不可区分混淆技术目前仍非常不成熟，现有的构造方案运行速度慢了数百万倍（甚至更多），无法在实际应用中使用。该技术因其运行时间 “理论上” 是多项式级别而广为人知，但实际运行需要的时间比宇宙寿命还长。尽管近期的协议已降低了极端的时间开销，但对于日常应用而言性能损耗仍然过高：据一位开发者估计，单次执行预计需要一年时间。
当前量子计算机尚未实现：目前网上所见的所有构想，要么是仅能处理 4 位运算的原型系统，要么不是真正意义的量子计算机——虽然它们可能包含量子组件，但无法执行实际有效的量子算法，如 Shor 算法或 Grover 算法。近期有迹象表明，“真正的” 量子计算机距离实现已不再那么遥远。然而，即便 “真正的” 量子计算机很快就会出现，普通人在笔记本电脑或手机上使用量子计算机的日子可能也比大型机构获得能够破解椭圆曲线密码的量子计算机晚几十年。
在不可区分混淆技术中，一个核心权衡点在于安全性假设。某些采用非常规假设的激进方案，虽然具有更实用的执行效率，但这些非常规假设往往存在被攻破的风险。随着对格密码学理论理解的深入，我们可能最终能够建立不可破解的假设。但这种路径风险较高。相对保守的路径是坚持使用可证明归约到 “标准假设” 的协议，但这意味着需要更长时间才能实现具备足够执行效率的协议。
它如何与路线图的其他部分互动？
强大的密码学技术可能彻底改变游戏规则。例如：
- 如果 ZK-SNARKs 的验证像签名一样简单，我们可能不再需要任何聚合协议，直接在链上完成验证。
- 一次性签名可能意味着更加安全的权益证明协议。
- 众多复杂的隐私协议可能被一个 “仅仅” 支持隐私保护的 EVM 所替代。
- 加密交易内存池的实现变得更加容易。
起初，这些创新效益将体现在应用层，因为以太坊 L1 本质上需要在安全性假设上保持保守。不过，仅在应用层的采用也可能带来革命性突破，堪比 ZK-SNARKs 的问世。
免责声明：作为区块链信息平台，本站所发布文章仅代表作者及嘉宾个人观点，与 Web3Caff 立场无关。文章内的信息仅供参考，均不构成任何投资建议及要约，并请您遵守所在国家或地区的相关法律法规。
