Vitalik:以太坊协议可能的未来—The Splurge

2024-10-29 11:40:57 68564

作者:以太坊创始人Vitalik;编译:邓通,金色财经

按:本文为以太坊创始人Vitalik近期发表的“以太坊协议的未来发展”系列文章的第六部分“Possible futures of the Ethereum protocol, part 6: The Splurge”,第五部分见“Vitalik:以太坊协议可能的未来—The Purge”,第四部分见“Vitalik:以太坊可能的未来The Verge”。第三部分见“Vitalik:以太坊The Scourge阶段的关键目标”,第二部分见“Vitalik:The Surge阶段以太坊协议应该怎么发展”,第一部分见“以太坊PoS还有哪些可以改进”。以下为第六部分全文:


特别感谢 Justin Drake 和 Tim Beiko 的反馈和评论。

有些事情很难归入一个类别。以太坊协议设计中有很多“小事情”对以太坊的成功非常有价值,但并不适合归入更大的子类别。实际上,其中大约一半最终与各种 EVM 改进有关,其余则由各种小众主题组成。这就是“the Splurge”的目的。

Ey0VpU7vRjjU5991shHqhcx3amJw3plYE8mgAhlf.jpeg

Splurge,2023 年路线图

The Splurge:主要目标

  • 将 EVM 带入高性能和稳定的“最终状态”

  • 将账户抽象化引入协议,让所有用户都能从更安全、更便捷的账户中受益

  • 优化交易费用经济,提高可扩展性,同时降低风险

  • 探索可以让以太坊在长期内变得更好的高级加密技术

EVM 改进

它解决了什么问题?

当今的 EVM 很难进行静态分析,因此很难创建高效的实现、正式验证代码以及随着时间的推移进行进一步扩展。此外,它的效率非常低,因此很难实现多种形式的高级加密技术,除非通过预编译明确支持它们。

它是什么,它是如何工作的?

当前 EVM 改进路线图的第一步是 EVM 对象格式 (EOF),计划包含在下一次硬分叉中。EOF 是一系列 EIP,用于指定具有许多独特功能的 EVM 代码的新版本,最值得注意的是:

  • 代码(可执行,但不能从 EVM 读取)和数据(可读,但不可执行)之间的分离。

  • 禁止动态跳转,仅允许静态跳转。

  • EVM 代码不再能观察到与 gas 相关的信息。

  • 添加了新的显式子程序机制。

vexhsqBXKIwFGUIpnpnF6o6GDkvDW970viatPNux.jpeg

EOF 代码的结构

旧式合约将继续存在并可创建,尽管最终可能会弃用旧式合约(甚至可能强制将其转换为 EOF 代码)。新式合约将受益于 EOF 带来的效率提升 —— 首先,利用子程序功能,字节码会略小,然后是新的 EOF 特定功能,或者 EOF 特定的 gas 成本会降低。

引入 EOF 后,引入进一步的升级变得更加容易。目前最完善的是 EVM 模块化算术扩展 (EVM-MAX)。EVM-MAX 创建了一组专为模块化算术设计的新操作,并将它们放入无法通过其他操作码访问的新内存空间中。这允许使用优化,例如蒙哥马利乘法。

一个较新的想法是将 EVM-MAX 与单指令多数据 (SIMD) 功能相结合。从 Greg Colvin 的 EIP-616 开始,SIMD 一直是以太坊的一个想法。SIMD 可用于加速多种形式的加密,包括哈希函数、32 位 STARK 和基于点阵的加密。EVM-MAX 与 SIMD 共同构成了 EVM 的一对以性能为导向的扩展。

组合 EIP 的近似设计是以 EIP-6690 为起点,然后:

  • 允许 (i) 任何奇数或 (ii) 2 的任何幂(最高 2^768)作为模数

  • 对于每个 EVMMAX 操作码(add、sub、mul),添加一个版本,该版本不是采用 3 个立即数 x、y、z,而是采用 7 个立即数:x_start、x_skip、y_start、y_skip、z_start、z_skip、count。在 Python 代码中,这些操作码将执行相当于以下操作的操作:

cNBz6r6lSdGzth3RwD7qzE8bsSjSGRIu1vIl3Sjs.jpeg

除非在实际实施中,它将被并行处理。

  • 可能的话,至少为 2 的幂模数添加 XOR、AND、OR、NOT 和 SHIFT(循环和非循环)。还添加 ISZERO(将输出推送到 EVM 主堆栈)。

这将足够强大,可以实现椭圆曲线密码术、小域密码术(例如 Poseidon、圆形 STARK)、传统哈希函数(例如 SHA256、KECCAK、BLAKE)和基于点阵的密码术。

其他 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。这些目标的摘要如下表所示:

H1zgVd7sDijV9duJNZiafWujqp5akPkBOzgehpGW.jpeg

这里的 MPC 是多方计算:一种已有 40 年历史的技术,将密钥拆分为多个部分,存储在多个设备上,并使用加密技术生成签名,而无需直接组合密钥的各个部分。

EIP-7702 是计划在下一次硬分叉中引入的 EIP。EIP-7702 是人们越来越认识到需要向所有用户(包括 EOA 用户)提供账户抽象的便利性,以在短期内改善每个人的用户体验,并避免分裂成两个生态系统的结果。这项工作始于 EIP-3074,最终在 EIP-7702 中达到顶峰。EIP-7702 使账户抽象的“便利功能”可供所有用户使用,包括 EOA(外部拥有的账户,即由 ECDSA 签名控制的账户)。

从图表中我们可以看出,虽然一些挑战(尤其是“便利性”挑战)可以通过多方计算或 EIP-7702 等渐进式技术解决,但最初提出账户抽象提案的大部分安全目标只能通过回过头来解决最初的问题:允许智能合约代码控制交易验证。到目前为止还没有做到这一点的原因是,安全地实施它是一项挑战。

它是什么?它是如何工作的?

从本质上讲,账户抽象很简单:允许通过智能合约(而不仅仅是 EOA)发起交易。整个复杂性来自于以一种有利于维护去中心化网络和防止拒绝服务攻击的方式做到这一点。

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

xUJKfgKIWjqY3Le2H3hQKtzoDzVVAlMc3QWJq03P.jpeg

如果有 1000 个账户的验证函数全部依赖于某个单一值 S ,并且内存池中存在根据 S 的当前值有效的交易,那么一个翻转 S 值的交易可能会使内存池中的所有其他交易无效。这允许攻击者以非常低的成本向内存池发送垃圾邮件,堵塞网络节点的资源。

多年来,在限制 DoS 风险的同时,试图扩展功能的努力已经导致人们就如何实现“理想账户抽象”的解决方案达成一致:ERC-4337。

BWdhUkoXJ6R9qywZcfSNWa0gwfv4PQhz33BmLh13.jpeg

ERC-4337 的工作方式是将用户操作的处理分为两个阶段:验证和执行。首先处理所有验证,然后处理所有执行。在内存池中,只有当用户操作的验证阶段仅触及自己的账户并且不读取环境变量时,用户操作才会被接受。这可以防止多重无效攻击。验证步骤还强制执行严格的 gas 限制。

ERC-4337 被设计为协议外标准 (ERC),因为当时以太坊客户端开发人员专注于合并,没有多余的能力来处理其他功能。这就是为什么 ERC-4337 使用自己的对象(称为用户操作)而不是常规交易的原因。然而,最近我们意识到有必要将其至少部分内容纳入协议中。两个主要原因是:

  • EntryPoint 作为合约的固有低效率:每个包的固定~100k gas 开销和每个用户操作的数千额外费用;

  • 需要确保以太坊属性(例如由包含列表创建的包含保证)延续到账户抽象用户。

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

  • 付款人:允许一个账户代表另一个账户支付费用的功能。这违反了在验证阶段只能访问发送方账户本身的规则,因此引入了特殊处理以允许付款人机制并确保其安全。

  • 聚合器:支持签名聚合的功能,例如 BLS 聚合或基于 SNARK 的聚合。这是在汇总上实现最高数据效率所必需的。

现有哪些研究?

账户抽象历史介绍: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 的嵌入 AA):https://eips.ethereum.org/EIPS/eip-7701

还剩下什么要做,又有哪些权衡?

剩下的主要问题是如何将账户抽象完全纳入协议。最近流行的账户抽象 EIP 是 EIP-7701,它在 EOF 之上实现账户抽象。账户可以有一个单独的代码部分用于验证,如果账户设置了该代码部分,那么该代码就会在该账户交易的验证步骤中执行。

djdB4qBfDbVzRyGRT6ahj3SvDSmW2wNqv1B8dxVs.jpegEIP-7701 账户的 EOF 代码结构

这种方法的迷人之处在于,它清楚地表明了两种等效的方式来查看本机账户抽象:

  • EIP-4337,但作为协议的一部分

  • 一种新型的 EOA,其中签名算法是 EVM 代码执行

如果我们首先严格限制验证期间可执行的代码的复杂性 —— 不允许外部状态访问,甚至一开始将 gas 限制设置得太低,以至于无法用于抗量子或隐私保护应用程序 —— 那么这种方法的安全性非常明显:它只是将 ECDSA 验证替换为需要类似时间的 EVM 代码执行。然而,随着时间的推移,我们需要放宽这些限制,因为允许隐私保护应用程序在没有中继器的情况下工作以及抗量子性都非常重要。为了做到这一点,我们确实需要找到以更灵活的方式来解决 DoS 风险的方法,而不需要验证步骤极其简单。

主要的权衡似乎是“尽快将更少人满意的东西奉为圭臬”,而不是“等待更长时间,也许会得到更理想的解决方案”。理想的方法可能是某种混合方法。一种混合方法是更快地将一些用例奉为圭臬,并留出更多时间来解决其他用例。另一种方法是首先在 L2 上部署更雄心勃勃的账户抽象版本。然而,这有一个挑战,即对于一个愿意努力采纳提案的 L2 团队来说,他们需要确信 L1 和/或其他 L2 稍后会采用兼容的东西。

我们需要明确考虑的另一个应用程序是密钥库账户,它将与账户相关的状态存储在 L1 或专用的 L2 上,但可以在 L1 和任何兼容的 L2 上使用。有效地做到这一点可能需要 L2 支持诸如 L1SLOAD 或 REMOTESTATICCALL 之类的操作码,尽管它也需要 L2 上的账户抽象实现来支持它。

它如何与路线图的其他部分交互?

包含列表需要支持账户抽象交易。实际上,包含列表的需求和去中心化内存池的需求最终非常相似,尽管包含列表的灵活性略高。此外,理想情况下,账户抽象实现应尽可能在 L1 和 L2 上协调一致。如果将来我们预计大多数用户都会使用密钥库汇总,那么账户抽象设计应该考虑到这一点。

EIP-1559 改进

它解决了什么问题?

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

LAGrDSoin0qchlcrOCSgugOfFM7CFfYZitHUCNqQ.jpeg

然而,EIP-1559 的当前实施在几个方面并不完善:

  • 该公式略有缺陷:它不是以 50% 的区块为目标,而是根据方差以 ~50-53% 的完整区块为目标(这与数学家所说的“AM-GM 不等式”有关);

  • 它在极端条件下调整得不够快。

后来用于 blob 的公式(EIP-4844)明确设计用于解决第一个问题,并且总体上更简洁。EIP-1559 本身和 EIP-4844 都没有尝试解决第二个问题。因此,现状是一种令人困惑的半途而废状态,涉及两种不同的机制,甚至有一种情况是,随着时间的推移,两者都需要改进。

除此之外,以太坊资源定价还有其他与 EIP-1559 无关的弱点,但可以通过调整 EIP-1559 来解决。一个主要问题是平均情况与最坏情况的差异:以太坊中的资源价格必须设置为能够处理最坏情况,即一个区块的整个 gas 消耗占用一种资源,但平均情况下的使用量远低于此,从而导致效率低下。

HEG3OJMRhboLP6jRQ9b3ByixRsdkLnv3QYRGORyU.jpeg

它是什么?它是如何工作的?

解决这些低效率问题的方法是多维 gas:对不同的资源设置不同的价格和限制。这个概念在技术上独立于 EIP-1559,但 EIP-1559 使其变得更容易:如果没有 EIP-1559,最佳地打包具有多个资源约束的块是一个复杂的多维背包问题。有了 EIP-1559,大多数块在任何资源上都没有满负荷,因此“接受支付足够费用的任何东西”的简单算法就足够了。

我们今天有多维 gas 用于执行和 blob;原则上,我们可以将其增加到更多维度:调用数据、状态读取/写入和状态大小扩展。

EIP-7706 为调用数据引入了一个新的 gas 维度。同时,它通过使所有三种类型的 gas 都属于一个(EIP-4844 风格)框架来简化多维 gas 机制,从而也解决了 EIP-1559 的数学缺陷。

EIP-7623 是针对平均情况与最坏情况资源问题的更精准的解决方案,它更严格地限制了最大调用数据,而无需引入全新的维度。

进一步的方向是解决更新率问题,并找到更快的基本费用计算算法,同时保留 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 限制:合约在调用其他合约时也会设置限制。而如今,他们设置限制的唯一方式是一维的。

消除此问题的一种简单方法是使多维 gas 仅在 EOF 内部可用,因为 EOF 不允许合约在调用其他合约时设置 gas 限制。非 EOF 合约在进行存储操作时必须支付所有类型的 gas 费用(例如,如果 SLOAD 花费了区块存储访问 gas 限制的 0.03%,则非 EOF 用户也将被收取执行 gas 限制的 0.03%)

对多维 gas 进行更多研究将有助于理解权衡并找出理想的平衡。

它如何与路线图的其他部分互动?

成功实施多维Gas可以大大减少某些“最坏情况”的资源使用,从而减轻优化性能以支持例如基于 STARKed 哈希的二叉树的压力。为状态大小增长设定一个硬性目标将使客户端开发人员更容易规划和估计他们未来的需求。

如上所述,由于 EOF 具有Gas不可观测性,因此更极端的多维Gas版本更容易实施。

可验证延迟函数 (VDF)

它解决了什么问题?

如今,以太坊使用基于 RANDAO 的随机性来选择提议者。基于 RANDAO 的随机性的工作原理是要求每个提议者透露他们提前承诺的秘密,并将每个透露的秘密混入随机性中。因此,每个提议者都有“1 位操纵权”:他们可以通过不露面来改变随机性(需要付出代价)。这对于寻找提议者来说是合理的,因为很少有人能通过放弃一个提议机会来给自己两个新的提议机会。但对于需要随机性的链上应用程序来说,这是不行的。理想情况下,我们会找到更强大的随机性来源。

它是什么?它是如何工作的?

可验证延迟函数是一种只能按顺序计算的函数,无法通过并行化加速。一个简单的例子是重复哈希:计算范围(10**9)中的 i:x = hash(x)。输出经过 SNARK 正确性证明,可用作随机值。这个想法是,输入是根据时间 T 时可用的信息选择的,而输出在时间 T 时尚不清楚:只有在有人完全运行计算后,它才会在 T 之后的某个时间可用。因为任何人都可以运行计算,所以不可能隐瞒结果,因此也没有能力操纵结果。

可验证延迟函数的主要风险是意外优化:有人想出了如何以比预期快得多的速度运行该函数,从而允许他们根据未来输出操纵他们在时间 T 时透露的信息。意外优化可能以两种方式发生:

  • 硬件加速:有人制造出一种 ASIC,其计算循环的运行速度比现有硬件快得多。

  • 意外的并行化:有人通过并行化找到了一种更快地运行该函数的方法,即使这样做需要 100 倍以上的资源。

创建成功的 VDF 的任务是避免这两个问题,同时保持效率实用(例如,基于哈希的方法的一个问题是实时的 SNARK 证明对硬件的要求很高)。硬件加速通常通过让公共利益参与者自己为 VDF 创建和分发合理接近最优的 ASIC 来解决。

现有哪些研究?

vdfresearch.org:https://vdfresearch.org/

2018 年对以太坊中使用的 VDF 的攻击思考: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 输出和需要输出之间会有一些“间隙”。这意味着信息将在几个区块之前可用。这可能是一个可接受的成本,但应该在单槽最终性或委员会选择设计等中加以考虑。

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

它解决了什么问题?

尼克·萨博最著名的帖子之一是 1997 年的一篇关于“上帝协议”的文章。在这篇文章中,他指出,多方应用程序通常依赖“受信任的第三方”来管理交互。在他看来,密码学的作用是创建一个模拟的受信任第三方来做同样的工作,而实际上不需要对任何特定参与者的信任。

IxS08h7BwysrcvsagLxRW0sTDUQiQw9XaJqmkBC7.jpeg

“数学上值得信赖的协议”,图表由 Nick Szabo 绘制

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

在 2010 年代,我们首次看到了一种基于可编程加密的不同且更强大的方法。我们可以使用强大的新协议(特别是 ZK-SNARK)为任意程序添加加密保证,而不是为每个新应用程序创建新协议。 ZK-SNARK 允许用户证明他们所持有的数据的任意陈述,其方式是:证明 (i) 易于验证,并且 (ii) 不会泄露除陈述本身之外的任何数据。这对隐私和可扩展性而言是一个巨大的进步,我将其比作人工智能中的变压器效应。数千人一年的特定应用工作突然被一个通用解决方案所取代,您只需插入该解决方案即可解决范围惊人的广泛问题。

但是 ZK-SNARK 只是三个类似的极其强大的通用原语中的第一个。这些协议非常强大,以至于当我想到它们时,它们让我想起了 Yu-Gi-Oh 中的一组极其强大的卡片,Yu-Gi-Oh 是一款纸牌游戏和电视节目,我小时候经常玩和看:埃及神卡。埃及神卡是三张极其强大的卡片,根据传说,制造它们可能致命,而且非常强大,以至于它们不允许用于决斗。同样,在密码学中,我们有三种埃及神协议:

q3YzuqjH3Nzo2Ul0EXW3euZONG1a1IxcBeoGpi8i.jpeg

它是什么?它是如何工作的?

ZK-SNARK 是我们已经拥有的三种协议之一,并且已经达到很高的成熟度。在过去五年中,ZK-SNARK 在证明速度和开发人员友好度方面取得了巨大进步,已成为以太坊可扩展性和隐私策略的基石。但 ZK-SNARK 有一个重要的限制:您需要了解数据才能对其进行证明。ZK-SNARK 应用程序中的每个状态都必须有一个“所有者”,该所有者必须在场批准对其的任何读取或写入。

第二个协议没有这个限制,即完全同态加密 (FHE)。FHE 允许您在不查看数据的情况下对加密数据进行任何计算。这允许您在用户数据上进行计算,以造福用户,同时保持数据和算法的私密性。它还允许您扩展 MACI 等投票系统,以获得近乎完美的安全性和隐私保障。长期以来,FHE 被认为效率太低,不适合实际使用,但现在它终于变得足够高效,我们开始看到应用。

MH04E8zonit1P0EthWwvD5X2JyNgQgDWlXrU46z8.jpeg

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

但 FHE 也有其局限性:任何基于 FHE 的技术仍然需要有人持有解密密钥。这可能是一个 M-of-N 分布式设置,你甚至可以使用 TEE 添加第二层防御,但这仍然是一个限制。

这让我们得到了第三个协议,它比其他两个协议加起来更强大:不可区分混淆。虽然它还远远没有成熟,但截至 2020 年,我们根据标准安全假设制定了理论上有效的协议,并且最近开始实施工作。不可区分混淆让你可以创建一个执行任意计算的“加密程序”,这样程序的所有内部细节都被隐藏了。举一个简单的例子,你可以把私钥放入一个混淆的程序中,这个程序只允许你用它来签署素数,并将这个程序分发给其他人。他们可以使用该程序对任何素数进行签名,但不能取出密钥。但它的功能远不止于此:与哈希一起使用,它可以用于实现任何其他加密原语,甚至更多。

混淆程序唯一不能做的就是防止自己被复制。但为此,还有更强大的东西即将出现,尽管这取决于每个人都拥有量子计算机:量子一次性签名。

xj6N29cPlqUcCRhoWyKnPv6WzXKsN7FYINTebw29.jpeg

结合使用混淆和一次性签名,我们可以构建几乎完美的无需信任的第三方。我们无法仅使用加密技术做到的唯一一件事,也是我们仍然需要区块链做到的事情,就是保证抗审查性。这些技术不仅能让我们使以太坊本身更加安全,还能在以太坊之上构建更强大的应用程序。

要了解这些原语中的每一个如何增加额外的功能,让我们来看一个关键的例子:投票。投票是一个令人着迷的问题,因为它有许多需要满足的棘手安全属性,包括非常强的可验证性和隐私性。虽然具有强大安全性的投票协议已经存在了几十年,但让我们通过说我们想要一个可以处理任意投票协议的设计来让问题变得更难:二次投票、成对有界二次融资、集群匹配二次融资等等。也就是说,我们希望“计票”步骤是一个任意程序。

  • 首先,假设我们将投票公开放在区块链上。这为我们提供了公开可验证性(任何人都可以验证最终结果是否正确,包括计票规则和资格规则)和审查阻力(不能阻止人们投票)。但我们没有隐私。

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

  • 现在,我们添加 MACI 机制。投票被加密到中央服务器的解密密钥。中央服务器需要运行计票过程,包括丢弃重复投票,并发布证明答案的 ZK-SNARK。这保留了先前的保证(即使服务器作弊!),但如果服务器是诚实的,它会增加一个强制抵抗保证:用户无法证明他们是如何投票的,即使他们想这样做。这是因为,虽然用户可以证明他们所投的票,但他们无法证明他们没有进行另一次取消该票的投票。这可以防止贿赂和其他攻击。

  • 我们在 FHE 内部运行计票,然后进行 N/2-of-N 阈值解密计算对其进行解密。这使得强制抵抗保证为 N/2-of-N,而不是 1-of-1。

  • 我们对计票程序进行了混淆,并设计了混淆程序,使其只有在获得许可的情况下才能给出输出,无论是通过区块链共识证明,还是通过一定数量的工作量证明,或者两者兼而有之。这使得强制抵抗保证几乎完美:在区块链共识的情况下,你需要 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-SNARK,我们可能不需要任何聚合协议;我们可以直接在链上验证。

  • 一次性签名可能意味着更安全的权益证明协议。

  • 许多复杂的隐私协议可以被“仅”拥有隐私保护 EVM 所取代。

  • 加密的内存池变得更容易实现。

首先,好处将出现在应用层上,因为以太坊 L1 本质上需要在安全假设上保守。然而,即使仅使用应用层也可能改变游戏规则,就像 ZK-SNARK 的出现一样。

声明:所有在本站发表的文章,本站都具有最终编辑权。本站全部作品均系微算力原创或来自网络转载,转载目的在于传递更多信息,并不代表本站赞同其观点和对其真实性负责,所产生的纠纷与本站无关。如涉及作品内容、版权和其它问题,请尽快与本站联系。

相关推荐

  • 微信:aspcool
  • QQ:580076
  • 手机:18992859886
  • 工作时间:9:00~18:00(周一至周五)