作者:Ethereum创始人Vitalik;编译:邓通,金色财经
按:本文为Ethereum创始人Vitalik近期发表的“Ethereum协议的未来发展”系列文章的第六部分“PossiblefuturesoftheEthereumprotocol,part6:TheSplurge”,第五部分见“Vitalik:Ethereum协议可能的未来—ThePurge”,第四部分见“Vitalik:Ethereum可能的未来TheVerge”。第三部分见“Vitalik:EthereumTheScourge阶段的关键目标”,第二部分见“Vitalik:TheSurge阶段Ethereum协议应该怎么发展”,第一部分见“EthereumPoS还有哪些可以改进”。以下为第六部分全文:
特别感谢JustinDrake和TimBeiko的反馈和评论。
有些事情很难归入一个类别。Ethereum协议设计中有很多“小事情”对Ethereum的成功非常有价值,但并不适合归入更大的子类别。实际上,其中大约一半最终与各种EVM改进有关,其余则由各种小众主题组成。这就是“theSplurge”的目的。
EOF代码的结构
旧式合约将继续存在并可创建,尽管最终可能会弃用旧式合约(甚至可能强制将其转换为EOF代码)。新式合约将受益于EOF带来的效率提升——首先,利用子程序功能,字节码会略小,然后是新的EOF特定功能,或者EOF特定的gas成本会降低。
引入EOF后,引入进一步的升级变得更加容易。目前最完善的是EVM模块化算术扩展(EVM-MAX)。EVM-MAX创建了一组专为模块化算术设计的新操作,并将它们放入无法通过其他操作码访问的新内存空间中。这允许使用优化,例如蒙哥马利乘法。
一个较新的想法是将EVM-MAX与单指令多数据(SIMD)功能相结合。从GregColvin的EIP-616开始,SIMD一直是Ethereum的一个想法。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代码中,这些操作码将执行相当于以下操作的操作:
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实现的简化以及其他好处。可以说,优先考虑持续改进EthereumL1的路线图将包括并建立在EOF之上。
一项重要的工作是实现类似EVM-MAX加SIMD的东西,并基准化各种加密操作需要多少gas。它如何与路线图的其他部分互动?
L1调整其EVM使L2更容易进行同样的调整。一个调整而另一个调整会产生一些不兼容性,这有其自身的缺点。此外,EVM-MAX加上SIMD可以降低许多证明系统的gas成本,从而实现更高效的L2。它还可以更轻松地删除更多预编译,方法是将它们替换为可以执行相同任务的EVM代码,而不必对效率造成很大的影响。账户抽象它解决了什么问题?
目前,交易只能通过一种方式进行验证:ECDSA签名。最初,账户抽象旨在超越这一点,并允许账户的验证逻辑为任意EVM代码。这可以实现一系列应用:
切换到抗量子加密技术;
轮换旧密钥(被广泛认为是一种推荐的安全做法);
多重签名钱包和社交恢复钱包;
使用一个密钥对低价值操作进行签名,使用另一个密钥(或一组密钥)对高价值操作进行签名;
允许隐私协议在没有中继器的情况下工作,大大降低其复杂性并消除关键的中心依赖点。
自2015年开始账户抽象以来,目标已经扩大到包括大量“便利目标”,例如没有ETH但有一些ERC20的账户能够用该ERC20支付gas。这些目标的摘要如下表所示:
如果有1000个账户的验证函数全部依赖于某个单一值S,并且内存池中存在根据S的当前值有效的交易,那么一个翻转S值的交易可能会使内存池中的所有其他交易无效。这允许攻击者以非常低的成本向内存池发送垃圾邮件,堵塞网络Node的资源。
多年来,在限制DoS风险的同时,试图扩展功能的努力已经导致人们就如何实现“理想账户抽象”的解决方案达成一致:ERC-4337。
ERC-4337的工作方式是将用户操作的处理分为两个阶段:验证和执行。首先处理所有验证,然后处理所有执行。在内存池中,只有当用户操作的验证阶段仅触及自己的账户并且不读取环境变量时,用户操作才会被接受。这可以防止多重无效攻击。验证步骤还强制执行严格的gas限制。
ERC-4337被设计为协议外标准(ERC),因为当时Ethereum客户端开发人员专注于合并,没有多余的能力来处理其他功能。这就是为什么ERC-4337使用自己的对象(称为用户操作)而不是常规交易的原因。然而,最近我们意识到有必要将其至少部分内容纳入协议中。两个主要原因是:
EntryPoint作为合约的固有低效率:每个包的固定~100kgas开销和每个用户操作的数千额外费用;
需要确保Ethereum属性(例如由包含列表创建的包含保证)延续到账户抽象用户。
此外,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之上实现账户抽象。账户可以有一个单独的代码部分用于验证,如果账户设置了该代码部分,那么该代码就会在该账户交易的验证步骤中执行。
然而,EIP-1559的当前实施在几个方面并不完善:
该公式略有缺陷:它不是以50%的区块为目标,而是根据方差以~50-53%的完整区块为目标(这与数学家所说的“AM-GM不等式”有关);
它在极端条件下调整得不够快。
后来用于blob的公式(EIP-4844)明确设计用于解决第一个问题,并且总体上更简洁。EIP-1559本身和EIP-4844都没有尝试解决第二个问题。因此,现状是一种令人困惑的半途而废状态,涉及两种不同的机制,甚至有一种情况是,随着时间的推移,两者都需要改进。
除此之外,Ethereum资源定价还有其他与EIP-1559无关的弱点,但可以通过调整EIP-1559来解决。一个主要问题是平均情况与最坏情况的差异:Ethereum中的资源价格必须设置为能够处理最坏情况,即一个区块的整个gas消耗占用一种资源,但平均情况下的使用量远低于此,从而导致效率低下。
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)它解决了什么问题?
如今,Ethereum使用基于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年对Ethereum中使用的VDF的攻击思考:https://ethresear.ch/t/verifiable-delay-functions-and-attacks/2365
对MinRoot(一种拟议的VDF)的攻击:https://inria.hal.science/hal-04320126/file/minrootanalysis2023.pdf还剩下什么要做,又有哪些权衡?
目前,还没有一种VDF结构能够完全满足Ethereum研究人员的所有需求。还需要做更多的工作来找到这样的功能。如果我们有它,主要的权衡只是是否包含它:功能与协议复杂性和安全风险之间的简单权衡。如果我们认为VDF是安全的,但最终却不安全,那么根据它的实施方式,安全性会降级为RANDAO假设(每个攻击者1位操纵)或更糟糕的情况。因此,即使VDF被破坏也不会破坏协议,但它会破坏应用程序或任何严重依赖它的新协议功能。它如何与路线图的其他部分交互?
VDF是Ethereum协议中相对独立的组成部分,但除了提高提议者选择的安全性之外,它还可用于(i)依赖于随机性的链上应用程序,以及潜在的(ii)加密内存池,尽管基于VDF制作加密内存池仍然依赖于尚未发生的其他加密发现。
需要记住的一点是,鉴于硬件的不确定性,在生成VDF输出和需要输出之间会有一些“间隙”。这意味着信息将在几个区块之前可用。这可能是一个可接受的成本,但应该在单槽最终性或委员会选择设计等中加以考虑。混淆和一次性签名:密码学的未来它解决了什么问题?
尼克·萨博最著名的帖子之一是1997年的一篇关于“上帝协议”的文章。在这篇文章中,他指出,多方应用程序通常依赖“受信任的第三方”来管理交互。在他看来,密码学的作用是创建一个模拟的受信任第三方来做同样的工作,而实际上不需要对任何特定参与者的信任。
它是什么?它是如何工作的?
ZK-SNARK是我们已经拥有的三种协议之一,并且已经达到很高的成熟度。在过去五年中,ZK-SNARK在证明速度和开发人员友好度方面取得了巨大进步,已成为Ethereum可扩展性和隐私策略的基石。但ZK-SNARK有一个重要的限制:您需要了解数据才能对其进行证明。ZK-SNARK应用程序中的每个状态都必须有一个“所有者”,该所有者必须在场批准对其的任何读取或写入。
第二个协议没有这个限制,即完全同态加密(FHE)。FHE允许您在不查看数据的情况下对加密数据进行任何计算。这允许您在用户数据上进行计算,以造福用户,同时保持数据和算法的私密性。它还允许您扩展MACI等投票系统,以获得近乎完美的安全性和隐私保障。长期以来,FHE被认为效率太低,不适合实际使用,但现在它终于变得足够高效,我们开始看到应用。
Cursive是一款使用双方计算和FHE进行共同兴趣的隐私保护发现的应用程序。
但FHE也有其局限性:任何基于FHE的技术仍然需要有人持有解密密钥。这可能是一个M-of-N分布式设置,你甚至可以使用TEE添加第二层防御,但这仍然是一个限制。
这让我们得到了第三个协议,它比其他两个协议加起来更强大:不可区分混淆。虽然它还远远没有成熟,但截至2020年,我们根据标准安全假设制定了理论上有效的协议,并且最近开始实施工作。不可区分混淆让你可以创建一个执行任意计算的“加密程序”,这样程序的所有内部细节都被隐藏了。举一个简单的例子,你可以把私钥放入一个混淆的程序中,这个程序只允许你用它来签署素数,并将这个程序分发给其他人。他们可以使用该程序对任何素数进行签名,但不能取出密钥。但它的功能远不止于此:与哈希一起使用,它可以用于实现任何其他加密原语,甚至更多。
混淆程序唯一不能做的就是防止自己被复制。但为此,还有更强大的东西即将出现,尽管这取决于每个人都拥有量子计算机:量子一次性签名。
https://eprint.iacr.org/2021/1334.pdf
混淆如何帮助Ethereum: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所取代。
加密的内存池变得更容易实现。
首先,好处将出现在应用层上,因为EthereumL1本质上需要在安全假设上保守。然而,即使仅使用应用层也可能改变游戏规则,就像ZK-SNARK的出现一样。
免责声明:Vitalik:Ethereum协议可能的未来—The Splurge文章转发自互联网,版权归其所有。
文章内容不代表本站立场和任何投资暗示。加密货币市场极其波动,风险很高,可能不适合所有投资者。在投资加密货币之前,请确保自己充分了解市场和投资的风险,并考虑自己的财务状况和风险承受能力。此外,请遵循您所在国家的法律法规,以及遵守交易所和钱包提供商的规定。对于任何因使用加密货币所造成的投资损失或其他损失,本站不承担任何责任。
Copyright © 2021.Company 元宇宙YITB.COM All rights reserved.元宇宙YITB.COM