• 元宇宙:本站分享元宇宙相关资讯,资讯仅代表作者观点与平台立场无关,仅供参考.

Vitalik:The Surge阶段Ethereum协议应该怎么发展

  • 2024年10月17日 22:44

按:本文为Ethereum创始人Vitalik近期发表的“Ethereum协议的未来发展”系列文章的第二部分“PossiblefuturesfortheEthereumprotocol,part2:TheSurge”,第一部分见金色财经此前报道“EthereumPoS还有哪些可以改进”。由金色财经邓通编译,以下为第二部分全文:

一开始,Ethereum的路线图中有两种扩展策略。

其中之一是“分片(sharding)”:每个Node只需要验证和存储一小部分交易,而不是验证和存储链中的所有交易。这也是任何其他点对点网络(例如BitTorrent)的工作原理,因此我们当然可以使Blockchain以同样的方式工作。

另一个是2层协议:网络将位于Ethereum之上,使它们能够充分受益于其安全性,同时使大多数数据和计算远离主链。“2层协议”指的是2015年的状态通道、2017年的Plasma,以及2019年的Rollups。Rollup比状态通道或Plasma更强大,但它们需要大量的链上数据带宽。

幸运的是,到2019年,分片研究已经解决了大规模验证“数据可用性”的问题。结果,两条路径融合了,我们得到了以Rollup为中心的路线图,这仍然是Ethereum今天的扩展策略。

qqspvBrss7g6upTmoxBsO5UFgQ3gMfQLJ9CRaTEc.jpeg

值得注意的是,三难困境不是定理,介绍三难困境的帖子没有附带数学证明。它给出了一个启发式的数学论证:如果一个Decentralization友好的Node(例如消费者笔记本电脑)每秒可以验证N个交易,并且您有一个每秒处理k*N个交易的链,那么(i)每个交易只能被看到1/k的Node,这意味着攻击者只需破坏几个Node即可推动不良交易,或者(ii)您的Node将变得强大并且您的链不是Decentralization的。这篇文章的目的从来不是为了表明打破三难困境是不可能的;相反,它是为了表明打破三难困境是困难的——它需要以某种方式跳出论证所暗示的框框进行思考。

多年来,一些高性能链经常声称他们解决了三难困境,而没有在基础架构层面采取任何巧妙的措施,通常是通过使用软件工程技巧来优化Node。这总是具有误导性,并且在此类链中运行Node总是比在Ethereum中困难得多。这篇文章探讨了为什么会出现这种情况的许多微妙之处(以及为什么L1客户端软件工程无法单独扩展Ethereum本身)。

然而,数据可用性采样(DAS)和SNARK的结合确实解决了三难困境:它允许客户端验证一定数量的数据是否可用,以及是否正确执行了一定数量的计算步骤,同时仅下载该数据的一小部分并且运行的计算量要小得多。SNARK是不可信的。数据可用性采样具有微妙的少数N信任模型,但它保留了不可扩展链所具有的基本属性,即使51%攻击也无法迫使网络接受坏块。

解决三难困境的另一种方法是Plasma架构,它使用巧妙的技术以激励兼容的方式将监视数据可用性的责任推给用户。早在2017-2019年,当我们扩展计算所需的只是欺诈证明时,Plasma的安全功能非常有限,但SNARK的主流化使得Plasma架构比以前更适用于更广泛的用例。DAS的进一步进展我们要解决什么问题?

截至2024年3月13日,当Dencun升级上线时,EthereumBlockchain每12秒时段有3个约125kB的“blob”,或者每个时段约375kB的数据可用带宽。假设交易数据直接发布到链上,ERC20传输约为180字节,因此Ethereum上rollups的最大TPS为:

375000/12/180=173.6TPS

如果我们添加Ethereum的calldata(理论最大值:每个插槽3000万个Gas/每字节16个Gas=每个插槽1,875,000字节),这将变为607TPS。对于PeerDAS,计划将blob计数目标增加到8-16,这将为我们提供463-926TPS的calldata。

这相对于EthereumL1来说是一个重大的提升,但这还不够。我们想要更多的可扩展性。我们的中期目标是每个插槽16MB,如果与汇数据压缩的改进相结合,将为我们提供约58,000TPS。PeerDAS是什么以及它是如何工作的?

PeerDAS是“一维采样”的相对简单的实现。Ethereum中的每个blob都是253位素数域上的4096次多项式。我们广播多项式的“份额”,其中每个份额由从总共8192个坐标集中获取的相邻16个坐标处的16个评估组成。8192次评估中的任意4096次(使用当前建议的参数:128个可能样本中的任意64个)都可以恢复该blob。

HdqHKm9ZagmTYb5FTlygncX1Pw5jnAWmlzJ77T5U.jpeg

2Dsampling.来源:a16z

至关重要的是,计算承诺的扩展不需要blob,因此该方案从根本上对分布式块构建是友好的。实际构建区块的Node只需要有BlobKZG承诺,并且自己可以依赖DAS来验证Blob的可用性。1DDAS本质上对分布式区块构建也很友好。与现有研究有哪些联系?

介绍数据可用性的原始文章(2018):https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding

后续论文:https://arxiv.org/abs/1809.09044

DAS的解释者帖子,范式:https://www.paradigm.xyz/2022/08/das

KZG承诺的2D可用性:https://ethresear.ch/t/2d-data-availability-with-kate-commitments/8081

ethresear.ch上的PeerDAS: https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541和论文:https://eprint.iacr.org/2024/1362

EIP-7594:https://eips.ethereum.org/EIPS/eip-7594

ethresear.ch上的SubnetDAS:https://ethresear.ch/t/subnetdas-an-intermediate-das-approach/17169

2D采样中可恢复性的细微差别:https://ethresear.ch/t/nuances-of-data-recoverability-in-data-availability-sampling/16256还需要做什么,需要权衡什么?

下一步是完成PeerDAS的实施和推出。从那时起,不断增加PeerDAS上的blob计数是一项渐进的工作,同时仔细观察网络并改进软件以确保安全。与此同时,我们希望开展更多关于PeerDAS和其他版本的DAS形式化及其与分叉选择规则安全性等问题的交互方面的学术工作。

展望未来,我们需要做更多的工作来找出2DDAS的理想版本并证明其安全特性。我们还希望最终从KZG迁移到抗量子、无需可信设置的替代方案。目前,我们不知道有哪些候选者对分布式区块构建友好。即使使用递归STARK来生成重建行和列的有效性证明的昂贵“强力”技术也不够,因为从技术上讲,STARK的哈希值大小为O(log(n)*log(log(n))(与STIR),实际上STARK几乎和整个斑点一样大。

从长远来看,我认为现实的路径是:

理想的2DDAS工具;

坚持使用1DDAS,为了简单性和robustness而牺牲采样带宽效率并接受较低的数据上限;

(硬枢轴)放弃DA,并完全拥抱Plasma作为我们关注的主要第2层架构。

我们可以通过权衡范围来看待这些:

VKjra1KFcFmCg2spPSwDV8DIushnYqHiYawxY6Lq.jpeg

最简单的增益就是零字节压缩:用两个表示零字节数量的字节替换每个长的零字节序列。更进一步,我们利用交易的特定属性:

签名聚合-我们从ECDSA签名切换到BLS签名,BLS签名具有可以将许多签名组合在一起形成单个签名的属性,该签名可以证明所有原始签名的有效性。L1没有考虑这一点,因为验证的计算成本(即使使用聚合)也更高,但在像L2这样的数据稀缺环境中,它们可以说是有意义的。ERC-4337的聚合功能提供了实现此目的的一种途径。

用指针替换地址-如果以前使用过地址,我们可以用指向历史位置的4字节指针替换20字节地址。这是实现最大收益所必需的,尽管需要付出努力才能实现,因为它需要(至少一部分)Blockchain的历史才能有效地成为国家的一部分。

交易值的自定义序列化-大多数交易值只有很少的数字,例如。0.25ETH表示为250,000,000,000,000,000wei。Gasmax-basefees和优先级费用的工作原理类似。因此,我们可以使用自定义十进制浮点格式,甚至是特别常见值的字典,非常紧凑地表示大多数货币值。与现有研究有哪些联系?

来自sequence.xyz的探索:https://sequence.xyz/blog/compressing-calldata

针对L2的Calldata优化合约,来自ScopeLift:https://github.com/ScopeLift/l2-optimizoooors

另一种策略-基于有效性证明的Rollup(又名ZKRollup)发布状态差异而不是交易:https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-on-l1/9975上的-l2-数据足迹

BLS钱包-通过ERC-4337实现BLS聚合:https://github.com/getwax/bls-wallet还需要做什么,需要权衡什么?

剩下要做的主要工作就是将上述方案落到实处。主要的权衡是:

切换到BLS签名需要付出巨大的努力,并且会降低与可提高安全性的可信硬件芯片的兼容性。可以使用其他签名方案的ZK-SNARK包装器来替代它。

动态压缩(例如用指针替换地址)使客户端代码变得复杂。

将状态差异发布到链而不是交易会降低可审计性,并使许多软件(例如区块浏览器)无法工作。它如何与路线图的其他部分交互?

ERC-4337的采用,以及最终将其部分内容纳入L2EVM中,可以大大加快聚合技术的部署。将ERC-4337的部分内容纳入L1可以加速其在L2上的部署。广义Plasma我们要解决什么问题?

即使使用16MBblob和数据压缩,58,000TPS也不一定足以完全接管消费者支付、Decentralization社交或其他高带宽领域,如果我们开始考虑隐私,情况就尤其如此,这可能会使可扩展性下降3-8x。对于大容量、低价值的应用程序,当今的一个选择是validium,它使数据处于链下状态,并具有有趣的安全模型,操作员无法窃取用户的资金,但它们可以消失并暂时或永久冻结所有用户的资金资金。但我们可以做得更好。它是什么以及它是如何工作的?

Plasma是一种扩展解决方案,涉及运营商在链外发布区块,并将这些区块的Merkle根放在链上(与Rollups不同,rollups是将整个区块放在链上)。对于每个区块,运营商向每个用户发送一个Merkle分支,证明该用户的资产发生了什么或没有发生什么。用户可以通过提供Merkle分支来提取资产。重要的是,该分支不必扎根于最新状态-因此,即使数据可用性失败,用户仍然可以通过撤回可用的最新状态来恢复其资产。如果用户提交无效分支(例如,退出他们已经发送给其他人的资产,或者运营商自己凭空创建资产),链上挑战机制可以裁定该资产正确属于谁。

qnRV0t7BgOc29LuPYcAWu9oCJufruwekosWuMFJQ.jpeg

制作EVMPlasma链的一种方法(不是唯一方法):使用ZK-SNARK构建并行UTXO树,反映EVM所做的余额变化,并定义什么是“同币”的唯一映射历史上的不同点。然后可以在此基础上构建Plasma结构。

一个重要的见解是Plasma系统不需要完美。即使您只能保护一部分资产(例如,即使只是过去一周没有移动的Tokens),您也已经大大改善了超可扩展EVM的现状,这是一个验证。

另一类结构是混合Plasma/rollups结构,例如Intmax。这些结构将每个用户的非常少量的数据放在链上(例如5字节),通过这样做,可以获得介于Plasma和Rollup之间的属性:在Intmax情况下,您可以获得非常高水平的可扩展性和隐私性,即使在16MB世界中,理论上容量上限也约为16,000,000/12/5=266,667TPS。与现有研究有哪些联系?

原始Plasma论文:https://plasma.io/plasma-deprecated.pdf

Plasma现金:https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298

Plasma现金流: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#-Exit

Intmax(2023):https://eprint.iacr.org/2023/1082还需要做什么,需要权衡什么?

剩下的主要任务是将Plasma系统投入生产。如上所述,“plasma与validium”不是二元对立:任何validium都可以通过将Plasma功能添加到退出机制中来至少提高一点点安全性能。研究部分是为了获得EVM的最佳属性(在信任要求、最坏情况的L1Gas成本和DoS脆弱性方面)以及替代的特定于应用程序的结构。此外,Plasma相对于rollups的概念复杂性更大,需要通过研究和构建更好的通用框架来直接解决。

使用Plasma设计的主要缺点是它们更多地依赖于操作员并且更难“基于”,尽管混合Plasma/rollup设计通常可以避免这个弱点。它如何与路线图的其他部分交互?

Plasma解决方案越有效,L1拥有高性能数据可用性功能的压力就越小。将活动移至L2还可减少L1上的MEV压力。成熟的L2证明系统我们要解决什么问题?

如今,大多数Rollup实际上还不是去信任的;有一个安全理事会有能力推翻(乐观或有效性)证明系统的行为。在某些情况下,证明系统甚至根本不存在,或者即使存在也仅具有“咨询”功能。最领先的是(i)一些特定于应用程序的Rollup,例如Fuel,它们是去信任的,以及(ii)截至撰写本文时,Optimism和Arbitrum,这两个完整的EVMRolup已经实现了部分去信任里程碑称为“第一阶段”。Rollups没有进一步发展的原因是担心代码中的bug。我们需要去信任的Rollup,因此我们需要正面解决这个问题。它是什么以及它是如何工作的?

首先,让我们回顾一下本文最初介绍的“stage”系统。还有更详细的要求,但总结如下:

第0阶段:用户必须能够运行Node并同步链。如果验证是完全可信/集中的就可以了。

第一阶段:必须有一个(去信任的)证明系统,确保只接受有效的交易。允许存在一个可以推翻证明系统的安全委员会,但只有75%的投票门槛。此外,理事会的法定人数阻止部分(即26%以上)必须位于构建Rollup的主要公司之外。允许使用功能较弱的升级机制(例如DAO),但必须有足够长的延迟,以便如果批准恶意升级,用户可以在升级上线之前退出资金。

第二阶段:必须有一个(不信任的)证明系统来确保只接受有效的交易。仅当代码中存在可证明的错误时,才允许安理会进行干预,例如。如果两个冗余证明系统彼此不一致,或者如果一个证明系统接受同一块的两个不同的后状态根(或者在足够长的时间内不接受任何内容,例如一周)。允许升级机制,但必须有很长的延迟。

我们的目标是达到第二阶段。达到第二阶段的主要挑战是获得足够的信心,证明证明系统实际上足够值得信赖。有两种主要方法可以做到这一点:

形式验证:我们可以使用现代数学和计算技术来证明(乐观或有效性)证明系统只接受通过EVM规范的区块。这些技术已经存在了几十年,但最近的进步(例如精益4)使它们更加实用,而人工智能辅助证明的进步可能会进一步加速这一趋势。

多重证明者:制作多重证明系统,并将资金投入这些证明系统和安全委员会(和/或其他具有信任假设的小工具,例如TEE)之间的2-of-3(或更大)多重签名。如果证明系统同意,则安理会没有权力。如果他们不同意,安理会只能选择其中之一,而不能单方面强加自己的答案。

cwsHADi2zE2sGk2hmCqw8t0hYshxLB3v3ArUHgvG.jpeg

一个病态糟糕的例子(甚至是危险的:我个人因为这里的链选择错误而损失了100美元)跨L2UX-虽然这不是Polymarket的错,但跨L2互操作性应该是钱包和Ethereum标准的责任(ERC))社区。在运行良好的Ethereum生态系统中,从L1到L2或从一个L2到另一个L2发送Tokens应该就像在同一个L1中发送Tokens一样。它是什么以及它是如何工作的?

跨L2互操作性改进有很多类别。一般来说,提出这些问题的方法是注意到理论上,以Rollup为中心的Ethereum与L1执行分片是一样的,然后询问当前的EthereumL2版本在实践中在哪些方面与理想的差距。以下是一些:

链特定地址:链(L1、Optimism、Arbitrum...)应该是地址的一部分。一旦实现,只需将地址放入“发送”字段即可实现跨L2发送流程,此时钱包可以在后台弄清楚如何进行发送(包括使用桥接协议)。

特定于链的支付请求:制作“向我发送Z链上Y类型的XTokens”形式的消息应该是简单且标准化的。这有两个主要用例:(i)支付,无论是个人对个人还是个人对商家的服务,以及(ii)请求资金的dapp,例如。上面的Polymarket例子。

跨链交换和Gas支付:应该有一个标准化的开放协议来表达跨链操作,例如“我在Optimism上发送1ETH给在Arbitrum上发送0.9999ETH的人”,以及“我在Optimism上发送0.0001ETH”任何人在Arbitrum上包含此交易”。ERC-7683是对前者的尝试,而RIP-7755是对后者的尝试,尽管两者都比这些特定用例更通用。

轻客户端:用户应该能够实际验证他们正在交互的链,而不仅仅是信任RPC提供商。A16zCrypto的Helios为Ethereum本身做到了这一点,但我们需要将这种去信任性扩展到L2。ERC-3668(CCIP-read)是实现此目的的一种策略。

PCHEpEQ3ya9wcyPDfJzf0aZw1DAgpjc9XProgmsK.jpeg

密钥库钱包如何工作的程式化图表。

更激进的“共享Tokens桥”想法:想象一个所有L2都是有效性证明Rollup的世界,每个插槽都致力于Ethereum。即使在这个世界上,“本地”将资产从一个L2转移到另一个L2也需要提取和存款,这需要支付大量的L1Gas。解决这个问题的一种方法是创建一个共享的最小Rollup,其唯一功能是维护哪个L2拥有多少种类型的Tokens的余额,并允许通过一系列交叉来集体更新这些余额。由任意L2发起的L2发送操作。这将允许跨L2传输发生,而无需每次传输支付L1Gas,也不需要基于流动性提供者的技术(如ERC-7683)。

同步可组合性:允许在特定L2和L1之间或多个L2之间发生同步调用。这可能有助于提高defi协议的财务效率。前者可以在没有任何跨L2协调的情况下完成;后者需要共享测序。基于Rollup自动对所有这些技术友好。与现有研究有哪些联系?

链特定地址:ERC-3770:https://eips.ethereum.org/EIPS/eip-3770

ERC-7683:https://eips.ethereum.org/EIPS/eip-7683

RIP-7755:https://github.com/wilsoncusack/RIPs/blob/cross-l2-call-standard/RIPS/rip-7755.md

滚动密钥库钱包设计:https://hackmd.io/@haichen/keystore

Helios: https://github.com/a16z/helios

ERC-3668(有时称为CCIP-read):https://eips.ethereum.org/EIPS/eip-3668

JustinDrake提出的“基于(共享)预确认”的提案:https://ethresear.ch/t/based-preconfirmations/17353

L1SLOAD(RIP-7728): https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388

乐观中的远程调用:https://github.com/ethereum-optimism/ecosystem-contributions/issues/76

AggLayer,其中包括共享令牌桥的想法:https://github.com/AggLayer还需要做什么,需要权衡什么?

上面的许多例子都面临着何时标准化以及标准化哪些层的标准困境。如果标准化太早,您可能会面临劣质解决方案的风险。如果标准化得太晚,就有可能造成不必要的碎片化。在某些情况下,既有性能较弱但更容易实施的短期解决方案,也有“最终正确”但需要相当长的时间才能实现的长期解决方案。

本节的独特之处在于,这些任务不仅仅是技术问题:它们也是(也许主要是!)社会问题。他们需要L2和钱包以及L1进行合作。我们成功处理这个问题的能力是对我们作为一个社区团结在一起的能力的考验。它如何与路线图的其他部分交互?

这些建议中的大多数都是“更高层”的结构,因此不会对L1考虑产生太大影响。一个例外是共享排序,它对MEV影响很大。扩展L1上的执行我们要解决什么问题?

如果L2变得非常可扩展且成功,但L1仍然只能处理非常少量的交易,那么Ethereum可能会出现许多风险:

ETH资产的经济状况变得更加危险,进而影响网络的长期安全。

许多L2受益于与L1上高度发达的金融生态系统的紧密联系,如果这个生态系统大大削弱,成为L2(而不是独立的L1)的动力就会减弱。

L2需要很长时间才能拥有与L1完全相同的安全保证。

如果L2发生故障(例如,由于恶意操作或消失的运营商),用户仍然需要通过L1才能恢复其资产。因此,L1需要足够强大,至少能够偶尔真正处理L2的高度复杂和混乱的结束。

出于这些原因,继续扩展L1本身并确保它能够继续适应越来越多的用途是很有价值的。它是什么以及它是如何工作的?

最简单的扩展方法就是简单地增加Gas限制。然而,这存在中心化L1的风险,从而削弱了使EthereumL1如此强大的另一个重要属性:其作为强大基础层的可信度。关于简单Gas限制增加到什么程度是可持续的一直存在争论,并且这也会根据其他技术的实施而发生变化,以使更大的区块更容易验证(例如历史到期、无状态、L1EVM有效性证明)。另一个需要不断改进的重要事情就是Ethereum客户端软件的效率,它今天比五年前更加优化。有效的L1Gas限制增加策略将涉及加速这些验证技术。

另一种扩展策略涉及识别特定的功能和计算类型,这些功能和计算类型可以在不损害网络分散性或其安全属性的情况下变得更便宜。这方面的例子包括:

EOF-一种新的EVM字节码格式,对静态分析更加友好,可以实现更快的实现。考虑到这些效率,可以给予EOF字节码较低的Gas成本。

多维Gas定价-建立单独的基本费用以及计算、数据和存储的限制可以增加EthereumL1的平均容量,而不增加其最大容量(从而产生新的安全风险)。

降低特定操作码和预编译的Gas成本-从历史上看,我们已经对某些定价过低的操作进行了几轮Gas成本的增加,以避免拒绝服务攻击。我们已经做得较少但可以做更多的事情,那就是降低价格过高的运营的Gas成本。例如,加法比乘法便宜得多,但ADD和MUL操作码的成本目前相同。我们可以使ADD更便宜,甚至更简单的操作码(例如PUSH)更便宜。EOF整体来说比较多。

EVM-MAX和SIMD:EVM-MAX(“模块化算术扩展”)是一项提议,允许更高效的原生大数模块化数学作为EVM的单独模块。由EVM-MAX计算计算出的值只能由其他EVM-MAX操作码访问,除非故意导出;这允许有更大的空间以优化的格式存储这些值。SIMD(“单指令多数据”)是一种允许在值数组上高效执行相同指令的提议。两者一起可以与EVM一起创建一个强大的协处理器,可用于更有效地实现加密操作。这对于隐私协议和L2证明系统特别有用,因此它将有助于L1和L2扩展。

这些改进将在以后关于Splurge的文章中更详细地讨论。

最后,第三种策略是原生Rollup(或“内置Rollup,enshrinedrollups”):本质上,创建并行运行的EVM的许多副本,从而形成一个与Rollup可以提供的模型等效的模型,但更原生地集成到协议中。与现有研究有哪些联系?

Polynya的EthereumL1扩容路线图:https://polynya.mirror.xyz/epju72rsymfB-JK52_uYI7HuhJ-W_zM735NdP7alkAQ

多维Gas定价:https://vitalik.eth.limo/general/2024/05/09/multidim.html

EIP-7706:https://eips.ethereum.org/EIPS/eip-7706

EOF:https://evmobjectformat.org/

EVM-MAX:https://ethereum-magicians.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168

SIMD:https://eips.ethereum.org/EIPS/eip-616

原生Rollup:https://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgogk6io1GE

采访MaxResnick关于扩展L1的价值:https://x.com/BanklessHQ/status/1831319419739361321

JustinDrake关于使用SNARK和原生Rollup进行扩展:https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/还需要做什么,需要权衡什么?

L1扩展有三种策略,可以单独或并行执行:

改进技术(例如客户端代码、无状态客户端、历史过期)使L1更容易验证,然后提高Gas限制

降低特定操作的成本,在不增加最坏情况风险的情况下提高平均容量

原生Rollup(即“创建EVM的N个并行副本”,尽管可能为开发人员在部署副本的参数方面提供了很大的灵活性)

值得理解的是,这些是具有不同权衡的不同技术。例如,原生Rollup在可组合性方面与常规Rollup有许多相同的弱点:您无法发送单个事务来跨多个事务同步执行操作,就像您可以在同一L1(或L2)上处理合约一样。提高Gas限制会剥夺通过使L1更易于验证而可以实现的其他好处,例如增加运行验证Node的用户比例以及增加单独的抵押者。使EVM中的特定操作更便宜(具体取决于操作方式)可能会增加EVM的总体复杂性。

任何L1扩展路线图都需要回答的一个大问题是:L1和L2的最终愿景是什么?显然,所有事情都在L1上进行是荒谬的:潜在的用例每秒有数十万个事务,这将使L1完全无法验证(除非我们采用原生Rollup路线)。但我们确实需要一些指导原则,这样我们才能确保我们不会造成这样的情况:我们将Gas限制提高10倍,严重损害EthereumL1的Decentralization,并发现我们只是进入了一个世界,而不是99%的活动都在L2上,90%的活动都在L2上,因此结果看起来几乎相同,除了EthereumL1的特殊性的大部分不可逆转的损失。

一种关于L1和L2之间“分工”的提议观点它如何与路线图的其他部分交互?

让更多用户进入L1意味着不仅要改善规模,还要改善L1的其他方面。这意味着更多的MEV将保留在L1上(而不是仅仅成为L2的问题),因此更迫切需要明确地处理它。它极大地增加了L1上快速时隙时间的价值。它还在很大程度上依赖于L1(“TheVerge”)的验证是否顺利。

特别感谢JustinDrake、Francesco、Hsiao-weiWang、@antonttc和GeorgiosKonstantopoulos

Copyright © 2021.Company 元宇宙YITB.COM All rights reserved.元宇宙YITB.COM