Skip to content

以太坊协议的可能未来 ❻:Splurge

作者:维塔利克·布特林 2024年10月29日 原文链接

有些内容很难纳入单一类别。在以太坊协议设计中,有许多"细小改进"对于以太坊的成功至关重要,但又难以归入某个更大的子类别。实际上,约一半涉及各种 EVM 相关优化,其余部分则是一些小众主题。这就是 The Splurge 的目的所在。

2023年路线图中的 The Splurge

特别感谢 Justin Drake 和 Tim Beiko 的反馈与审阅

说明

为 Vitalik 文章的全文翻译,为便于阅读增加少量标签式图示展示重要术语。

The Splurge:关键目标

  • 将 EVM 提升至高性能且稳定的"最终状态"
  • 将帐户抽象引入协议层,让所有用户从更安全便捷的帐户中受益
  • 优化交易费用经济模型,提高可扩展性同时降低风险
  • 探索先进的密码学创新,长远来看可以极大提升以太坊

本章内容

  • EVM 优化
  • 账户抽象
  • EIP-1559 改进
  • VDF
  • 混淆与一次性签名:密码学的远景

EVM 改进

我们要解决什么问题?

当前 EVM 很难进行静态分析,这使得创建高效实现、正式验证代码以及推出后续扩展变得很有挑战。此外,EVM 效率低下,如果不通过预编译程序显式支持,很难实现诸如高级密码学等复杂操作。

EOF

它是什么?工作原理是什么?

EVM 改进路线图的第一步是 EVM 对象格式 (EOF),计划在下一次硬分叉中引入。EOF 是一系列 EIP,规定了一个新版本的 EVM 代码格式,具有以下几个显著特征:

  • 代码(可执行但 EVM 无法读取)和 数据(可读但不可执行)分离存储
  • 禁止动态跳转(无法在运行时任意跳转),只允许静态跳转(编译时已确定的跳转目标)。这提高了可预测性和安全性
  • EVM 代码无法再获取 gas 相关信息
  • 添加了新的显式子程序机制,有助于减小代码体积

旧式合约仍可继续创建,但未来可能被逐步淘汰或强制转换为 EOF 格式。新式合约将从 EOF 带来的优化中获益,首先是略小的字节码体积(利用子程序特性),后续还可能有更多 EOF 专属的新特性或 gas 费用下调。

在引入 EOF 后,将更容易推出进一步的 EVM 升级。目前最成熟的提案是 EVM 模块化算术扩展 (EVM-MAX),它为模运算创建了一组新的操作码,并将它们置于一个独立的内存区域,无法通过其他操作码访问。这样就能使用优化技术,如 Montgomery 乘法。

另一个较新的想法是将 EVM-MAX 与单指令多数据(SIMD)特性相结合。SIMD 作为一种想法在以太坊社区已有较长历史,最早来自 Greg Colvin 的 EIP-616。SIMD 可用于加速多种密码学算法,包括哈希函数、32位 STARKs 和基于格的密码学。EVM-MAX 加上 SIMD 是对 EVM 实现两大面向性能的扩展。

一个合并 EVM-MAX 和 SIMD 的近似设计方案是以 EIP-6690 为基础,然后:

  • 允许任何奇数或任何小于等于 2768 次方的 2 作为模数
  • 对于每个 EVMMAX 操作码(加、减、乘),添加一个新版本,它不是接受 3 个立即数 x、y、z,而是接受 7 个立即数:x_start、x_skip、y_start、y_skip、z_start、z_skip、count。用 Python 表示,这些新操作码的作用相当于:
python
for i in range(count):
    mem[z_start + z_skip * i] = op(
        mem[x_start + x_skip * i],
        mem[y_start + y_skip * i]
    )

不过实际实现将以并行的方式处理。

  • 可能还会为 2 的幂模数添加 异或(XOR)、与(AND)、或(OR)、非(NOT)和位移(SHIFT,包括循环和非循环两种)等操作码,还会加入 ISZERO 操作码(将输出推送到 EVM 主栈)。

这一综合方案将足以高效实现椭圆曲线密码学、小域密码学算法(如 Poseidon、circle STARKs)、常见哈希函数(如 SHA256、KECCAK、BLAKE)以及基于格的密码学算法。

除了上述 EVM-MAX 和 SIMD 方案,其他 EVM 升级虽有可能,但目前关注度较低,提案和讨论不太活跃。

查看更多:现有研究资料链接

现有研究资料链接

待解决的问题及权衡考虑

目前,EOF计划在下一次硬分叉中实施。尽管理论上总有可能在最后关头将其移除——之前的硬分叉中也曾发生过这种情况——但要做到这一点将面临重重阻力。移除EOF意味着,未来对EVM进行任何升级时都不得不绕开EOF,虽然可行但会更加困难。

在EVM发展中,需要权衡的是L1复杂度与基础设施复杂度之间的平衡。将EOF纳入各个EVM实现无疑会大幅增加代码量,其中的静态代码检查也非常复杂。但作为回报,我们将获得更简洁的高级语言、更精简的EVM实现,以及其他好处。从这个角度来说,一个优先推进以太坊L1持续改进的路线图自然也将纳入并建立在EOF之上。

当下一个急需完成的重要工作,是实现类似于EVM-MAX加SIMD的方案,并对各种密码学运算的gas消耗进行基准测试。

与路线图其他部分的关系

L1对EVM的调整有利于L2采纳相同的调整方式。如果L1和L2在EVM的改动上出现分歧,就会导致兼容性问题,产生一定的弊端。此外,EVM-MAX加SIMD方案可以降低诸多密码学证明系统的gas消耗,从而提高L2的整体效率。它还为将来逐步移除预编译合约(precompile)奠定了基础,届时可以在不过度牺牲执行效率的前提下,用等效的EVM字节码指令来替代预编译合约的功能。

上述种种方面的进展都将为L2的发展营造更加有利的环境,从而与以太坊路线图的其他部分形成良性互动。

账户抽象

账户抽象(账户验证逻辑可编程性)

我们要解决什么问题?

当今,交易只能通过一种方式进行验证:ECDSA签名。最初,账户验证逻辑可编程性的设计目标是超越这一点,允许账户的验证逻辑由任意的EVM代码控制。这可以实现一系列应用:

  • 切换到量子抗性密码学
  • 轮换旧密钥(广为人知的推荐安全实践)
  • 多重签名钱包和社交恢复钱包
  • 对低价值操作使用一个密钥签名,对高价值操作使用另一个密钥(或一组密钥)签名
  • 允许隐私协议在不依赖中继器的情况下工作,大大降低了它们的复杂性,并消除了关键的中央依赖点

自该功能开始设计以来,其目标已扩展到包括大量"便利性目标",例如持有某种ERC20但没有ETH的账户能够使用该ERC20支付gas手续费。下图总结了这些目标:

图中 MPC 指的是多方计算(multi-party computation):一种四十年历史的技术,将密钥分散存储在多个设备上,并使用加密技术在不直接组合密钥片段的情况下生成签名。

EIP-7702是计划在下一次硬分叉中引入的EIP。EIP-7702的产生是由于人们日益认识到,有必要让所有用户(包括EOA用户)都能享受账户验证逻辑可编程性带来的便利性收益,从而在短期内改善每个人的用户体验,并避免分化为两个生态系统。这项工作始于EIP-3074,最终形成了EIP-7702。EIP-7702使账户验证逻辑可编程性的"便利性"功能可用于所有用户,包括EOA(外部拥有账户, 即由ECDSA签名控制的账户)。

从图中可以看出,虽然一些挑战(特别是"便利性"挑战)可以通过增量技术(如多方计算或EIP-7702)来解决,但推动最初账户验证逻辑可编程性提案的大部分安全目标只能通过解决原始问题来实现:允许智能合约代码控制交易验证。目前尚未实现的原因是,以安全的方式实现这一点是一个挑战。

它是什么?工作原理是什么?

账户抽象的核心思想很简单:允许由智能合约而不仅仅是外部拥有账户(EOA)发起交易。所有复杂性来自于以一种有利于维护去中心化网络并防御拒绝服务攻击的方式来实现这一点。

一个说明关键挑战的例子是多重无效化问题:

如果有1000个账户的验证函数都依赖于某个单一值S,而内存池中有一些在当前S值情况下有效的交易,那么一笔单独翻转S值的交易就可能使内存池中所有其他交易无效。这使得攻击者能够以极低的成本向内存池发送垃圾交易,从而堵塞网络节点资源。

EIP-4337

经过多年努力扩展功能同时限制拒绝服务风险,最终收敛到一个实现"理想账户抽象化"的解决方案:ERC-4337

ERC-4337通过将用户操作(user operation,特殊类型的交易对象)处理分为两个阶段:验证执行。首先处理所有验证,然后处理所有执行。在内存池中,只有当用户操作的验证阶段只涉及自己的账户,并且不读取环境变量时,才会被接受。这样可以防止多重无效化攻击。在验证步骤上也强制执行了严格的gas限制。

ERC-4337最初被设计为一个额外的协议标准(ERC),因为当时以太坊客户端开发者正专注于合并工作,暂时无力兼顾其他功能的开发。这就是为什么ERC-4337使用了自己的交易对象叫做"user operation",而不是普通交易。然而,最近我们意识到有必要将其中至少一部分纳入以太坊协议本身。主要有两个原因:

  1. EntryPoint(入口点合约)作为一个智能合约,存在固有的低效性:每个交易包裹大约需要100k gas的固定开销,每个用户操作还需要数千gas的额外开销。
  2. 需要确保以太坊的固有属性(如包含列表带来的可靠包含保证)也适用于账户抽象化用户的交易。

此外,ERC-4337标准还扩展了两个新功能:

  • 代付人(Paymaster): 允许一个账户代表另一个账户支付交易手续费。这违反了在验证阶段只允许访问发送方账户自身的规则,因此引入了特殊处理机制来允许代付人功能并确保其安全性。
  • 聚合器(Aggregator): 支持签名聚合技术,如BLS聚合或基于SNARK的聚合。这对于在rollup层实现最高级别的数据传输效率是必需的。
查看更多:现有研究资料链接

现有研究资料链接

待解决的问题及权衡考虑

主要剩余的工作是如何将帐户抽象完全引入协议。最近备受关注的一个实现帐户抽象的EIP是EIP-7701,它在EOF的基础上实现了帐户抽象。账户可以有一个单独的验证代码部分,如果某账户设置了该代码部分,那么在该账户发起的交易的验证步骤中,就会执行该代码。

EIP-7701账户的EOF代码结构

这种方法很有趣的一点在于,它清楚地展示了有两种等效的方式来看待原生帐户抽象:

  1. EIP-4337,但作为协议的一部分
  2. 一种新型EOA,其中签名算法是EVM代码执行

如果我们从对可在验证过程中执行的代码复杂度设置严格限制开始 - 不允许访问外部状态,甚至一开始就设置一个对于量子抗衡或隐私保护应用来说过低的gas限制 - 那么这种方法的安全性是非常明确的:它只是用EVM代码执行替换了ECDSA验证,而所需时间相似。然而,随着时间推移,我们需要放松这些限制,因为允许隐私保护应用无需中继者即可工作,以及实现量子抗衡,这两点都非常重要。为了做到这一点,我们确实需要以更灵活的方式来解决DoS风险,而不是要求验证步骤必须极其简单化。

主要的权衡是"尽快纳入一些让较少人满意的内容"与"等待更长时间,或许能得到更加理想的解决方案"。理想的做法可能是某种混合方式。一种混合方式是先快速纳入一些使用案例,然后留出更多时间来解决其他问题。另一种方法是先在L2上部署更雄心勃勃的账户抽象版本。但后一种方法的挑战在于,要让L2团队愿意付出工作采用某个建议方案,他们需要有信心L1和/或其他L2最终会采用兼容的方案。

我们还需要明确考虑的另一个应用是keystore账户,它们将与账户相关的状态存储在L1或专用L2上,但可以同时用于L1和任何兼容的L2。有效地实现这一点可能需要L2支持诸如L1SLOADREMOTESTATICCALL之类的操作码,同时也需要L2上的账户抽象实现对此提供支持。

与路线图其他部分的关系

包含列表需要支持使用帐户抽象的交易。实际上,包含列表和去中心化内存池的需求最终是相当相似的,尽管包含列表有稍微更大的灵活性。此外,L1和L2上的帐户抽象实现应该尽可能协调一致。如果将来我们预期大多数用户将使用keystore rollup,那么在设计帐户抽象时就应该将此考虑在内。

EIP-1559

EIP-1559改进方案

我们要解决什么问题?

EIP-1559 于2021年在以太坊上线,显著改善了平均区块打包时间。

然而,目前EIP-1559的实施仍存在一些不足:

  • 公式有瑕疵:它所瞄准的并非50%的满块比例,而是大约50-53%的满块比例,这取决于方差(这与数学家所说的"AM-GM不等式"有关)
  • 反应速度不够快 ,在极端情况下调整缓慢。

后来为Blob设计的公式(EIP-4844)旨在解决第一个问题,整体更为简洁高效。但无论是EIP-1559本身还是EIP-4844,都没有尝试解决第二个问题。因此,现状是一种令人困惑的过渡状态,同时采用两种不同的机制,而且从长远来看,这两种机制都可能需要进一步改进。

除此之外,以太坊资源定价还存在其他一些与EIP-1559无直接关联的缺陷,但或许可以通过对EIP-1559进行调整来加以解决。其中一个主要问题是平均情况与最坏情况之间的差异:由于以太坊的资源价格必须足以应对最坏情况情形(即一个区块的所有gas消耗都集中在单个资源上),这就导致在平均使用情况下资源利用率偏低、效率不佳。

多维 gas 定价

它是什么?工作原理是什么?

解决这些效率问题的一种方案是多维 gas 定价:为不同的资源类型设置独立的价格和上限。这一概念在技术层面上与EIP-1559无直接关联,但EIP-1559却使其更容易实施:如果没有EIP-1559,在多个资源约束条件下最优化一个区块的组成内容,就会变成一个复杂的多维背包问题。而在EIP-1559机制下,大多数区块都不会在任何一种资源上达到饱和状态,因此简单地"接受任何支付了足够手续费的交易"这一算法就足够了。

如今我们已经在执行层和Blob层采用了多维 gas定价;原则上,我们可以进一步增加更多的维度,比如Calldata状态读/写状态大小膨胀

EIP-7706 就引入了一个新的Calldata gas维度。同时,它将所有三种类型的gas统一纳入了一个(类似EIP-4844的)框架之下,从而简化了多维 gas机制,也由此解决了EIP-1559存在的数学缺陷。

EIP-7623则提出了一种更为精细的解决方案,来缓解平均情况与最坏情况之间的资源利用率差异,它更为严格地限制了Calldata的最大值,而无需引入一个全新的维度。

未来的一个发展方向是解决basefee更新速率的问题,找到一种更快速的基础费计算算法,同时保留EIP-4844机制引入的关键不变量(即:从长远来看,平均使用率恰好接近目标值)。

查看更多:现有研究资料链接

现有研究资料链接

待解决的问题及权衡考虑

多维 gas 存在两大主要权衡:

  • 它增加了协议的复杂性
  • 它增加了填充区块容量所需最优算法的复杂性

对于calldata而言,增加协议复杂性的影响相对较小,但对于那些"在EVM内部"的gas维度(如存储读写)来说,影响就更大了。问题在于,不仅用户需要设置gas限制,当合约调用其他合约时也需要设置。而如今,它们设置限制的唯一方式是一维的。

一个简单的解决方案是,只允许在EOF内实施多维 gas,因为EOF不允许合约在调用其他合约时设置gas限制。非EOF合约进行存储操作(如SLOAD消耗0.03%的块存储访问gas限制)时,需要同时支付所有类型gas的费用(如此例中非EOF用户也需缴纳0.03%的执行gas限制费用)。

深入研究多维 gas将有助于我们理解其中的权衡,找到最佳的平衡。

与路线图其他部分的关系

成功实现多维 gas可以大幅降低某些"最坏情况"下的资源使用,从而减轻优化性能以支持例如被STARK化的基于哈希的二叉树所需承担的压力。为状态增长规模设置一个上限,将使客户端开发人员更好地规划和估算未来的需求。

如前所述,由于EOF具有gas不可观测性这一特性,它能更好地支持实现更加极端的多维 gas版本。

VDF

可验证延迟函数 (VDF)

它解决了什么问题?

当前,以太坊使用基于RANDAO的随机数来选择出块者。基于RANDAO的随机数的工作方式是要求每个出块者公开他们事先承诺的秘密,并将每个公开的秘密混入随机数。因此,每个出块者都拥有"1位操纵能力":他们可以通过不露面来改变随机数(付出代价)。对于选择出块者来说,这是相当不错的,因为你很少能通过放弃一个机会就获得两个新的出块机会。但对于需要随机性的链上应用来说,这是不够的。理想情况下,我们应该找到一个更加可靠的随机源。

它是什么?工作原理是什么?

可验证延迟函数是一种只能顺序计算的函数类型,无法通过并行化获得加速。一个简单的例子是基于重复哈希计算的方法:执行for i in range(10*9): x = hash(x)。计算出的输出,配合正确性的 SNARK 证明,可以用作随机值。其思想是输入基于时间T可获得的信息选择,而输出在时间T时尚未知晓:它只有在某人完全运行计算之后才能得到。由于任何人都可以运行该计算,所以没有隐藏结果的可能性,也就无法操纵结果。

可验证延迟函数的主要风险是意外优化:有人找到了比预期快得多的运行函数的方式,从而可以根据未来输出来操纵他们在时间T披露的信息。意外优化可能出现在两种方式:

  • 硬件运算加速: 有人制造了可以比现有硬件更快运行计算循环的专用芯片。
  • 意外并行化: 尽管需要耗费大量资源,有人发现了一种通过并行化来更快运行该函数的方法。

创建成功的VDF的任务是避免这两个问题,同时保持实用的效率(例如,基于重复哈希计算的方法的一个问题是实时 SNARK 证明哈希需要繁重的硬件要求)。硬件运算加速通常通过由公共利益行为者创建和分发针对VDF本身的相当接近最优的专用芯片来解决。

查看更多:现有研究资料链接

现有研究资料链接

待解决的问题及权衡考虑

目前,还没有一种VDF构造方法能够在所有方面都完全满足以太坊研究者的要求。我们需要继续努力来寻找这样的函数。如果找到了,主要需要权衡的是,是否将其纳入协议:功能性与协议复杂度及安全风险之间进行简单权衡。如果我们认为某个VDF是安全的,但最终被发现存在漏洞,那么根据其具体实现,安全性或会降低到RANDAO假设(即每个攻击者最多只能操纵1位),或者略微更糟一些。因此,即使VDF存在缺陷,也不会破坏整个协议,只会影响依赖于VDF的应用程序或新协议功能。

与路线图其他部分的关系

VDF是以太坊协议中一个相对独立的组成部分,除了提高提议者选择的安全性之外,它还可应用于(i)依赖随机性的链上程序,以及(ii)可能的加密内存池,不过后者基于VDF的实现还需要一些尚未出现的新的密码学发现。

需要注意的一点是,由于硬件的不确定性,在VDF输出产生和需要使用之间,会有一些时间差。这意味着,相关信息会提前几个区块就可获取。这个代价是可以接受的,但在设计单时隙终结或委员会选择等功能时,仍需将其考虑在内。

混淆和一次性签名:密码学的遥远未来

它解决了什么问题?

尼克·萨博(Nick Szabo)最著名的文章之一是1997年关于"上帝协议"的论文。在这篇文章中,他指出多方应用程序通常依赖于一个"受信任的第三方"来管理交互。他认为,密码学的作用是创建一个模拟受信任的第三方的机制,执行相同的工作,但不需要对任何特定的参与者产生信任。

"数学上可信的协议",图片来自尼克·萨博

到目前为止,我们只能部分地接近这一理想。如果我们只需要一个透明的虚拟计算机,其中数据和计算不会被关闭、审查或篡改,但隐私并非目标,那么区块链就可以做到,尽管可扩展性有限。如果隐私是目标,那么直到最近,我们只能为特定应用程序创建一些特定协议:数字签名用于基本身份认证、环签名可链接环签名用于基本匿名形式、基于身份的加密在特定关于受信任发行者的假设下实现更方便的加密、盲签名用于 Chaumian电子现金等等。这种方法需要为每一个新应用做大量工作。

在2010年代,我们第一次看到了一种不同的、更强大的方法,基于可编程密码学。我们不是为每个新应用程序创建新协议,而是使用功能强大的新协议——具体来说是ZK-SNARKs(same)——为任意程序添加密码学保证。ZK-SNARKs允许用户以一种(i)易于验证且(ii)不会泄露陈述本身之外的任何数据的方式,证明有关他们持有数据的任意陈述。这在隐私和可扩展性方面都是一个巨大的飞跃,我将之比作人工智能中 Transformer(深度学习架构)的作用。成千上万人年的特定应用工作 ,突然被一种通用解决方案所取代,你只需插入即可解决令人惊讶的广泛问题。

但ZK-SNARKs只是一个三重极其强大的通用原语中的第一个。这些协议是如此强大,以至于当我思考它们时,它们让我想起了我小时候玩和观看的游戏和电视节目《游戏王》中一组非常强大的卡片:埃及神之卡(same)。据说制造埃及神之卡可能是致命的,而且它们如此强大以至于在对决中被禁止使用。同样,在密码学中,我们有埃及神协议三重奏:

它是什么?工作原理是什么?

ZK-SNARK

ZK-SNARK是我们现有的三种协议之一,已经达到了较高的成熟度。在过去五年里,证人的速度和对开发者的友好性有了大幅提升,ZK-SNARK已成为以太坊可扩展性和隐私策略的基石。但ZK-SNARK有一个重要限制:你需要知道数据,才能为其生成证明。ZK-SNARK应用程序中的每一部分状态都必须有一个"所有者",他必须随时准备就绪,以批准对其进行任何读取或写入。

FHE

第二种协议是完全同态加密(FHE),该协议没有上述限制。FHE允许你在不看见数据的情况下对加密数据进行任何计算。这使你可以为用户的利益对用户的数据进行计算,同时保持数据和算法的隐私。它还允许你扩展诸如MACI之类的投票系统,以获得近乎完美的安全和隐私保证。长期以来,FHE被认为效率太低,无法实际使用,但现在它终于变得足够高效,我们开始看到一些应用诞生。

Cursive是一款使用两方计算和FHE进行隐私保护兴趣发现的应用程序

与此同时,FHE也存在局限。任何基于FHE的技术,仍然需要 某个人 持有解密密钥。这种人虽然可以采用 M-of-N 分布式设置,甚至可以使用TEE添加第二层防御,但终究是一种限制。

obfuscation

这让我们进入了第三种协议,它所具有的能力比前两种协议的组合更为强大,那就是不可区分混淆(indistinguishability obfuscation)。尽管它目前仍然非常远离成熟应用的阶段,但截至2020年,我们有了基于标准安全假设的理论上有效协议,而且最近也开始着手实现。不可区分混淆允许你创建一个"加密程序",执行任意计算,以便完全隐藏程序的所有内部细节。例如,你可以将私钥放入一个混淆的程序中,该程序只允许你对质数签名,并将此程序分发给其他人。他们可以使用该程序对任何质数签名,但无法取出密钥。但它的功能远不止于此:结合哈希,它可用于实现任何其他加密原语,甚至更多。

混淆程序唯一不能做到的是防止自身被复制。不过,即将到来的一种更为强大的方案将能解决这个问题——尽管它需要每个人都拥有量子计算机,那就是量子一次性签名( quantum one-shot signatures,一种量子签名技术,只能使用一次)。

通过隐蔽性和一次性签名,我们可以构建几乎完全无需信任的第三方。我们仅凭密码学无法做到的,并且仍需要区块链的,就是确保抗审查能力。这些技术不仅可以使以太坊本身更加安全,还可以在其之上构建更强大的应用程序。

让我们通过一个关键的示例来看看每一种基元如何增加额外的能力:投票。投票是一个迷人的问题,因为它需要满足许多棘手的安全性要求,包括非常强大的可验证性和隐私性。尽管具有强大安全性的投票协议已经存在了几十年,但让我们为自己增加难度,假设我们希望拥有一种设计,可以处理任意的投票协议:二次方投票成对限制二次方资助集群匹配二次方资助等等。也就是说,我们希望"统计"步骤是任意程序。

  • 首先,假设我们将投票公开记录在区块链上。这给我们带来了公开可验证性(任何人都可以验证最终结果是否正确,包括统计规则和资格规则)和防审查能力(无法阻止人们投票)。但我们没有隐私性保证。

  • 然后,我们添加ZK-SNARK。现在,我们有了隐私性:每张选票都是匿名的,同时确保只有授权的投票者可以投票,并且每个投票者只能投一次票。

  • 现在,我们添加MACI机制。所有投票都被加密到中央服务器的解密密钥中。中央服务器需要运行统计过程,包括剔除重复投票,并发布ZK-SNARK来证明最终结果。这保留了前面的保证(即使服务器作弊!)。但如果服务器诚实,它还增加了一个防胁迫保证:用户无法证明他们如何投票,即使他们想这样做。这是因为虽然用户可以证明他们所做的投票,但他们没有办法证明他们没有做出另一张选票来抵消该投票。这可以防止贿赂和其他攻击。

  • 我们在 全同态加密(FHE) 中运行统计程序,然后使用N/2-of-N 阈值解密计算将其解密。这使得防胁迫保证1对1变为N/2对N

  • 我们对统计程序进行隐蔽,并设计隐蔽后的程序,使其只有在获得许可时才能给出输出,无论是通过区块链共识的证明,还是一些工作量证明,或两者兼而有之。这使防胁迫保证近乎完美:在区块链共识的情况下,你需要51%的验证者勾结才能破坏它;在工作量证明的情况下,即使每个人都勾结,尝试通过重新运行不同子集的投票者的统计来试图提取单个投票者的行为也将代价极其昂贵。我们甚至可以使程序对最终统计结果做一个小的随机调整,从而使提取单个投票者行为变得更加困难。

  • 我们添加一次性签名,这是一种依赖于量子计算的基元,它允许签名只能用于一次签名某种类型的消息。这使防胁迫保证真正完美。一次性签名确保每个人的投票都是绝对匿名和不可追踪的,从而消除了任何形式的强迫或贿赂的可能性。

通过一次性签名,我们可以使区块链免受撤销最终性的51%攻击,但仍有可能遭受审查攻击。类似一次性签名的基础设施可实现量子货币,在无需区块链的情况下解决双重支付问题,但许多更复杂的应用仍需要区块链。

如果这些基础设施的效率足够高,世界上大多数应用都可以去中心化。主要的瓶颈将是验证实现的正确性。

查看更多:现有研究资料链接

现有研究资料链接

待解决的问题及权衡考虑

确实还有大量工作要做。 不可区分混淆(indistinguishability obfuscation)目前仍处于非常初级的阶段,而现有的候选构造运行速度极其缓慢,以致于无法在实际应用中使用(如果不是更慢的话)。对称加密技术因具有"理论上"的多项式时间运行而广为人知,但在实践中运行起来需要比宇宙历史还要久远的时间。近期的一些协议虽然使运行时间不那么极端,但是运算开销依然过高,无法常规使用:据某位实现者预计,运行时间长达一年之久。

量子计算机目前甚至还不存在:你在互联网上看到的所有相关内容,要么只是无法进行超过 4 位运算的原型设备,要么根本就算不上是真正的量子计算机,因为它们尽管或多或少包含了量子部件,但无法运行诸如Shor 算法Grover 算法等实质性的计算。不过最近确实有一些迹象表明,真正的量子计算机可能来临已不远矣。然而即便真正的量子计算机很快问世,普通人能在自己的笔记本电脑或手机上使用量子计算机的那一天,也可能要比主要机构率先拥有一台能够破解椭圆曲线加密的量子计算机晚几十年。

在对称加密技术中,关键的权衡在于安全性假设。有一些更积极的设计采用了奇特异域假设,这些设计通常在运行速度上表现更为实际,但这些异域假设有时会被证伪。随着时间推移,我们对于格等问题的理解可能会加深到足以制定出不会遭到证伪的假设。然而这种路径风险更大。相对更为保守的路径则是坚持使用基于"标准"假设的协议,其安全性能够被证明归约为某些标准假设,但代价是可能要等待更长时间才能获得运算速度足够快的协议。

与路线图其他部分的关系

一旦极其强大的加密技术问世,整个局面可能会发生天翻地覆的变化。比如:

  • 如果我们获得了与验证数字签名一样简单高效的 ZK-SNARK(零知识简洁非交互式知识证明),就可能不再需要任何聚合(aggregation)协议,直接在链上进行验证即可。
  • 一次性签名(one-shot signatures)或将意味着更加安全的权益证明(proof-of-stake)协议。
  • 许多复杂的隐私保护协议都可以被一个"仅"具有隐私保护功能的 EVM(以太坊虚拟机)所取代。
  • 实现加密交易内存池(encrypted mempools)将变得更加简单。

起初这种影响会首先体现在应用层,因为以太坊主链在安全性假设方面必须保持足够谨慎。但即便只应用于应用层,这种影响力也可能堪比零知识证明技术的出现一样具有颠覆性,带来游戏规则的根本转变。

ETHStudy (An Ethereum Ecosystem Initiative)
Supported by Uweb(University of Web3)