区块链网站|NFTS Aptos(APT) StarkNet:发布性能路线图 为TPS的改进做准备

StarkNet:发布性能路线图 为TPS的改进做准备

广告位

StarkNet:发布性能路线图,为改进TPS做好准备

声明:本文旨在传递更多市场信息,不构成任何投资建议。文章仅代表作者观点,不代表MarsBit官方立场。

边肖:记得要集中注意力。

资料来源:马斯比特

概述

L2不像L1那样受到吞吐量的限制。这为L2有效性累计带来了更高的TPS。

StarkNet性能路线图解决了系统中的一个关键元素:定序器。

我们在这里展示了性能改进的路线图:

Sequencer并行化Cairo-VM的新Rust实现在Rust Verifier中重新实现sequencer,可以处理比现在更多的事情。

介绍

大约一年前,StarkNet在主要网络上发布。起初,我们专注于构建StarkNet的功能。目前,我们将通过一系列步骤重点改善性能,这将有助于提升StarkNet的体验。

在本文中,我们将解释为什么广泛的优化只适用于有效性汇总,并分享我们在StarkNet上实施这些步骤的计划。其中一些步骤已经在StarkNet Alpha 0.10.2中实现,该版本在测试网(11月16日上线)和主网(11月28日上线)发布。但是在讨论解决方案之前,让我们回顾一下块限制问题及其原因。

块空间限制:有效性累计和L1

提高区块链的可扩展性和TPS的一个潜在方法是在保持块时间恒定的同时解决块限制(就气体/大小而言)。这将需要砌块生产商(L1的验证商、L2的分拣商)付出更多努力,并更有效地实施这些组件。为此,我们现在将重点关注StarkNet sequencer优化,我们将在接下来的章节中对此进行更详细的描述。

这里自然会有问题。为什么序列器优化仅限于有效性汇总,也就是为什么不能在L1上实现同样的提升,完全避免有效性汇总的复杂性?在下一节中,我们将解释两者之间的根本区别,允许对不适用于L1的L2进行大量优化。

为什么L1的吞吐量有限?

不幸的是,解除对L1的封锁将遭遇一个重大陷阱。通过增加区块链的增长率,我们也增加了对所有节点的需求,这些节点试图跟上最新的状态。由于L1所有节点都要重新执行所有的历史记录,块间隔的大量增加(就Gas而言)会给它们带来巨大的压力,这将再次导致较弱的机器(节点)退出系统,将保持所有节点运行的能力归还给足够大的实体。最终,用户将无法验证他们的状态并以不信任的方式参与网络。

这让我们明白,L1的吞吐量应该受到限制,以维持一个真正分散和安全的系统。

为什么同样的问题不影响有效性Rollup?

只有站在所有节点的角度,才能看到Validity Rollup提供的真正力量。L1需要重新执行整个事务历史,以确保当前状态的正确性。STARKNet节点只需要验证Stark证明,这种验证占用的计算资源量呈指数级下降。特别是,从零开始的同步不一定涉及执行;一个节点可以从它的对等节点接收当前状态的转储,并且它只能通过严格的证明来验证该状态是否有效。这使我们能够在不增加所有节点要求的情况下增加网络的吞吐量。

因此,我们得出结论,L2测序仪会影响整个优化范围,但这在L1上是不可能的。

未来性能路线图

在下一节中,我们将讨论StarkNet测序仪目前使用的计划。

序列器并行化

我们路线图的第一步是将并行性引入事务执行。这是昨天在主网站发布的StarkNet alpha 0.10.2中介绍的。现在让我们深入了解一下什么是并行化(这是半技术性的部分,请跳到下一节继续关注路线图)。

那么“事务并行化”是什么意思呢?并行执行一个事务块是不可能的,因为不同的事务可能相互依赖。下面的例子说明了这一点。包含来自同一用户的三个事务的块:

交易a:用USDC换ETH。

交易B:为NFT支付ETH

交易C:BTC的美元T

显然,Tx A必须出现在Tx B之前,但是Tx C完全独立于二者,可以并行执行。如果每个事务执行需要1秒,那么通过引入并行化,阻塞时间可以从3秒减少到2秒。

问题的关键在于,我们事先并不知道交易的依赖性。实际上,只有当我们执行示例中的事务B时,我们才能看到它依赖于事务A所做的更改。此外,这种依赖性源于事务B从事务A写入的内存单元中读取。我们可以将事务绘制为依赖关系图,其中存在从事务A到事务B的执行,当且仅当A被写入B读取的存储单元中时,因此它必须在B之前执行。下图显示了依赖关系图的示例:

在上面的例子中,每一列都可以并行执行,这是最好的安排(天真地说,我们将按顺序执行事务1-9)。

为了克服我们事先不知道依赖图的情况,我们借鉴Aptos实验室开发的BLOCK-STM的精神,将最优性并行性引入StarkNet sequencer。在这种范式下,我们乐观地尝试并行运行事务,并在发现冲突时重新执行它们。例如,我们可以并行执行图1中的事务1-4,然后发现Tx4依赖于Tx1。因此,它的执行是无用的(我们针对Tx1运行的相同状态运行它,但是我们应该针对通过应用Tx1生成的状态运行它)。在这种情况下,我们将重新执行Tx4。https://malkhi.com/posts/2022/04/block-stm/

请注意,我们可以在优化并行性之上添加许多乐观主义者。例如,我们可以在发现使执行无效的依赖时停止执行,而不是天真地等待每次执行的结束。

另一个例子是优化重新执行哪些事务的选择。假设图1中包含所有事务的块被发送到一个有五个CPU内核的序列器。首先,我们尝试并行执行事务1-5。如果完成顺序是Tx2、Tx3、Tx4、Tx1,最后是Tx5,那么只有在Tx4已经执行完之后,才会发现依赖Tx1Tx4——的指令要重新执行。天真地说,我们可能还想重新执行Tx5,因为考虑到Tx4的新执行,它的行为可能会有所不同。但是,我们可以遍历通过执行终止的事务构建的依赖图,只重新执行依赖Tx4的事务,而不是只重新执行Tx4之后所有现在无效的事务。

Cairo-VM的新Rust实现

StarkNet中的智能合同是用Cairo编写的,在Cairo-VM中执行,规范出现在Cairo白皮书中。目前,sequencer使用的是Cairo-VM的python实现。为了优化VM实现的性能,我们启动了用Rust重写VM的工作。感谢Lambdaclass的出色工作。他们现在是StarkNet生态系统中非常有价值的团队,这项工作很快就会有成果。

vmrust实现Cairo-rs现在可以执行本地Cairo代码。下一步是处理智能契约的执行以及与pythonic sequencer的集成。一旦与cairo-rs集成,定序器的性能有望得到显著提升。

Rust中序列器的重新实现

我们从python到rust的转换以提高性能并不局限于Cairo VM。除了上述改进,我们还计划从Rust开始,重写sequencer。除了Rust的先天优势,也为音序器的其他优化提供了想象空间。举几个例子,我们可以享受cairo-rs的好处,而无需为python-rust通信付费,我们可以完全重新设计存储和访问状态的方式。

证明者

在整篇文章中,我们没有提到有效性汇总中最著名的元素3354 prover。可以想象,作为架构中最复杂的组件,应该是瓶颈所在,所以也是优化的重点。有趣的是,现在StarkNet的瓶颈是更“标准”的组件。今天,特别是对于递归证明,我们可以将比测试网络/主网络上的当前流量更多的事务放入证明中。事实上,目前StarkNet block已经与StarkEx交易一起被证明,有时会产生几十万的NFT铸造交易。

摘要

并行化,生锈等。——为即将到来的StarkNet版本中改进的TPS做好了准备。

广告位
本文来自网络,不代表区块链网站|NFTS立场,转载请注明出处:https://www.qklwz.com/jzb/apt/19296.html

作者: 炒面多吃

上一篇
下一篇

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

返回顶部