Sui, Aptos, Solana 的技术(并行执行)之争(Sui和Aptos项目方的联合 创始人 纷纷加入讨论)

guanghua
发布于 阅读 2337

争论原因

Babacus 书写的 Aptos 不是Solana 杀手 一文

Babacus 解释了自己 没有持有大量的apt和solana代币,是站在技术的公正的角度来书写的该文章。
该文主要内容如下:

Ethereum策略:

解释了以太坊是单行的执行逻辑,不能并行处理。Aptos 和 Solana 都是基于以太坊不能并行处理的缺陷去设计自己的优化方案。以高速公路公路的通用列子来阐述 并行处理逻辑。以太坊是单车道高速公路, Aptos 和Solana 是多车道高速公路。

Sonala策略:

需要 提前安排指定不同的车辆 只能走多车道高速公路的某一条道。 Aptos 想解决Sonala 的这个痛苦的事先安排车辆在指定的道路上行驶。

Aptos策略:

采用“Block STM”算法,在不知道这些汽车将使用哪些车道的情况下将汽车添加到同一个“block”。这些汽车按顺序排列,就好像它们只有一条车道一样(类似于 eth)。 当 Aptos 执行者收到该区块时,执行者能够在执行期间指定汽车车道,指定不同车道的汽车放置在不同的车道上。

Aptos 存在的问题:

事先不知道每个block要包含后面 汽车,只会按照 gas的高低来挑选汽车,那么会导致如下图的现象:价高的汽车都是同一条车道的,而其他并行的车道完全没车辆。实际执行时aptos的Block-STM 算法可能导致并行 进入最差解,和Ethereum的单车道效果没区别。

Solana 更优于Aptos 的理由。

Solana 强制汽车预先指定车道。虽然这可能会使开发更加痛苦,但它允许“汽车选择”系统使用车道信息来选择汽车。 Solana 的“汽车选择器”可以基于每条车道限制一个Block中的汽车数量:

Aptos CTO avery 对此文观点作出了回应。

大概意思是:
Block-STM 比预先声明依赖关系的模型强大得多。当预先不知道依赖关系时,预先声明依赖关系会破坏可组合性(例如,拆分交易)——例如,哪个用户赢得了拍卖。
拆分事务是不自然的,增加了延迟,浪费了更多的系统资源,并使编程变得更加困难(例如,如何从多个事务的错误情况中恢复?)。 Block-STM 会增加两个 算法(乐观并行性 和聚合器)来解决上面所提到的Aptos 并行车道 陷入到最 差解。其次, Solana的事先程序员安排,不是算法的高明,是人为的苦力解决问题,和算法无关。

Sui 的加入

此时,还没有Sui什么事情, 但 Aptos 的Move 开发Leader 发推 引入了Sui CTO 的讨论。

Sui CTO Sam Blackshear的发推。

对于这个讨论,Sui被卷入,Sui CTO表示一脸懵逼。 因为Sui没有 像 Solana 那样预先安排车辆车道的逻辑, 也解释了Sui 如何实现 Aptos CTO所提的 Solana策略不能解决并行拍卖的问题。 并总结, Sui Move 是在Diem Move 上迭代优化而来的,有很多Diem Move 没有的功能。
具体技术内容可以查看Sui 的RFC

Sui CPO Adeniyi Abiodun 发推力挺 Sam

Sui CPO 说:Sui Move 实现了跨越式发展,超越了 Meta 开发的内容。

Sui CTO Sam Blackshear 明白了整个争论的点,总结了Sui一直以来取得的最前沿成绩。


Sam的言论翻译如下:
Sam 总结了 Babacus 提到的并行执行遇到的三个重要问题

  • 1, 并行执行只会增加可并行工作负载的吞吐量。
  • 2, 良好的费用模型通过惩罚对相同 QoS 的更高费用的竞争来确保您获得这样的工作量。
  • 3, 需要强制性静态信息——如果您只是发现一个交易在执行时创建了竞争,那么惩罚该交易或奖励其他没有创建竞争的交易就来不及了。

Sam 添加了并行执行的第四点重要问题: 编程人员想要一个能够以尽可能细的粒度表达“通道”的编程模型。

该帖子(合理地)通过假设每辆车占用一条车道而过于简化,但实际上一辆典型的汽车(tx)将占用多条车道,每条车道对应它接触的每个内存块。例如,跨 2 个 DEX 执行套利的 tx 将触及 2 个块。

如果这些块是细粒度的(例如,每个 DEX 池一个对象),与粗粒度的块(例如,DEX 中所有货币对的一个大哈希表)相比,您可以更容易地表达不存在竞争。
在前一种方法中,SUI <-> DOGE 套利将独立于 USDC <-> BTC 套利,但在后一种方法中,涉及相同两个 DEX 的所有交易都会发生冲突。你想要前者。
在设计 Sui 时,我们考虑了很多关于为细粒度访问提供最方便的编程模型,同时还启用(1)/(2):每个对象都有自己的通道,并且 tx 指定它接触的对象。
我从未听过 Sui 开发人员抱怨静态依赖(OP 承认这对 Solana 开发人员来说是痛苦的),因为他们没有注意到——Sui 交易需要最少数量的信息来传达意图:

  • 如果你接触 2 个 DEX 池,你指定这些池的 ID。
  • 如果您要在市场上列出 NFT,请提供 NFT 的 ID 和市场的 ID。
  • 如果您要将一个对象转移给另一个用户,您需要提供该对象的 ID 和接收者的地址(并且有 0 个争用!)。

这与您在没有静态访问信息的系统中必须提供的信息相同,但 Sui 利用此信息提供 (2) 和许多其他好处(例如,跳过许多常见交易的排序、钱包交易权限。
相比之下,Solana 开发人员必须经常为简单的交易指定许多依赖项,尤其是在涉及组合时。
@kklas
在这篇史诗般的帖子的第 5.3 节中给出了一个很好的例子: Solana rust和Sui Move编程的并行对比,其中先铸币后交换需要 Sui 上的 3 个输入和 Solana 上的 17 (!) 。

我非常同意 Solana 的静态信息和本地费用市场的理念(并钦佩他们在开拓后者方面所做的工作),但我认为开发人员不需要为了获得这些好处而受苦。 Sui 的可组合对象让您既能做蛋糕又能吃蛋糕。

Sui CEO Evan Cheng 发推 力挺 Sui 的并行技术和Sui CTO。 说 Sam 的讨论是区块链并行编程模型的权威讨论。


Evan 还指出,一个交易的并行执行有很多道工序,一个完整的工序包括(内存池 -> 共识 -> 执行 -> merkel 状态树更新)。这上面提及的每一道工序都可能是并行执行的瓶颈。 Sui的并行执行逻辑不像 Aptos/Solana,只在执行阶段并行,而是在上面提及的每一个工序都做并行处理。

总结

作为开发人员的我,认识到了这次讨论的意义, Sam 总结的并行执行的4个重点问题,是区块链并行要解决的根本问题。Sui Move 用Object 和Object ID的抽象,把并行执行 做到了细粒度。正如 Sam所说的,Sui Move 的可组合性Object 既能让开发者方便编程,又能让交易最大粒度的并行执行。

标签: Sui
评论