原文作者:Mysten Labs首席执行官兼联合创始人Evan Cheng

译文:《Sui创始人亲笔:以“挤公交”为例阐述Sui的性能优势》by Azuma

Sui创始人:以“挤公交”为例,阐述Sui被大家忽视的关键创新

过去一段时间,市面上出现了解析 Sui 的文章,但这些文章大多数都错过了一项最关键的创新 —— Sui 的数据模型及交易处理通道。我将在接下来的推文中分三部分就此进行解释:

Part1:传统区块链的交易处理通道

Part2:Sui 的交易处理通道

Part3:Sui 的优势

区块链的运行逻辑是,随着时间的推移,验证者们会共同向链上添加新的区块。交易处理通道位于「构建区块——共识——执行——更新默克尔树」这套流程的最前方,所有交易在向该流程的下游继续推进之前必须被处理。而当新的区块开始构建之时,交易的处理也会被暂停。

下面是一幅关于传统区块链的交易处理通道及其问题的示意图。我们已看到许多项目都在尝试在用不同的方法解决这些问题。

Sui创始人:以“挤公交”为例,阐述Sui被大家忽视的关键创新

Sui 的做法是通过「对象(objects)」 来区分、组织数据。某款 NFT 、某个代币的余额、某项智能合约,这些都是不同的对象(可以理解为类型),意味着 Sui 链上的交易可以根据对象的不同来分组处理。

下图是一个简单的例子,描述了可分为 3 组的 5 笔不同交易(稍后我们将回来继续聊特定对象和共享对象)。这 3 组交易完全可以实现并行处理。

Sui创始人:以“挤公交”为例,阐述Sui被大家忽视的关键创新

而在其它传统的区块链中,单个区块内所有不相关的交易都需要依次处理。比如 Bob 向 Bruce 发送了一个 BAYC NFT,Alice 向 Alex 发送了一个 Punk NFT,Jane 用了某个 DEX 等等,所有这些交易都需要按照共识集体排序,执行,并最终表现在默克尔树上。

打个比方,这就像是坐公交车。在传统区块链上,所有乘客必须排队(共识)上车,每一位乘客都需要在发车前检票(执行),然后再于同一个地点下车(默克尔树更新),只有当公交车再次空开之后才能继续容纳新乘客,链才能继续向前运行;而在 Sui 之上,链会根据目的地(对象)对所有旅客进行分组,各组旅客的票都会并行检查,然后再由不同的车辆并行送往目的地。

Sui 的创新并不仅仅在于交易的并行处理(关于这点,未来会分享更多内容),交易结果在执行之后也会被提交至对象(比如某个代币的余额为 10,发送了 5,余额还剩 5),它们可以被立即用作未来交易的输入(input)。Sui 将默克尔树作为了新建区块的部分检查点,待一系列相关交易最终确定后才会记账。

此外需要注意的一点是,在前文的案例中,有些交易只对应一个特定的对象,比如只有 Bob 可以发起关于他所拥有的 BAYC NFT 的交易。特定对象类的交易可以跳过共识(只需要拜占庭一致广播),因为所有者可以确认交易顺序。

而对于另一类的交易,即所谓的共享对象型交易(比如 DEX 智能合约),则必须经过协商一致,因为没有单一的所有者来决定顺序。这就是我们 Narwhal & Bullshark 共识的用武之地。

简单来说就是,特定对象类交易可以并行执行,共享对象型交易彼此间也可并行执行,但在各个共享的对象是需要顺序执行的(这里应用了其他静态/动态技术)。

总而言之,你可以理解为:

- 对于常规区块链来说,所有交易都需要集体排序,然后执行。

- 对于 Sui 来说,所有交易都会根据一定的逻辑区分、整理后再排序,然后执行。数据模型可以使不同交易之间的依赖关系更清晰,只有共享对象的交易才需要集体排序,特定对象的交易则不需要这一共识协商过程。

那么,Sui 的这一架构可以解决哪些产品问题呢?让我们继续往下看。

首先是水平扩容的能力。在 Sui 之上,每组交易都是并行处理的,这就好比是前文说的每组旅客都会乘坐不同的车,所以如果有更多组旅客(交易),Sui 只需要再配备更多的车。关于这一点,Sui 可以通过内部验证器来分片扩容 —— 更多的工作者去处理更多的交易。

为什么水平扩展扩容的能力很重要?想一想一些大型项目在考虑底层时的需求吧,他们需要确保底层可以承载其规模的持续增长,有性能上限的区块链将成为这些项目入驻的阻碍,Sui 的设计正是为了应对这样的需求高峰。

其次是可组合性。有什么是在 Sui 上可行,但在其他智能合约平台上不可行的?比如将资产作为参数传递给函数,比如从函数中返还某种资产,再比如将资产存储在一个数据结构内,或是直接存储在另一个资产内。

以后我可能会专门再写一篇关于可组合性的推文,因为这是一个相当复杂的主题。我只想说,Sui 在合约级别和资产级别(不同类型的对象可以嵌套在其他对象中)显著提高了可组合性。

再然后是部分重播的能力。区块链提供了所有交易的历史记录,这对检查过往信息很有帮助。然而,如果某个产品需要关心一些链上数据,读取可能会非常昂贵。Sui 的构架允许这些项目只关注它们所关心的对象的演化,即部分重播。

例如,一款将所有角色放在 Sui 上的 RPG 游戏可以简单地观看代表着这些角色的对象。他们不需要从默克尔树数据结构中挖掘所有数据。

最后是链上存储。各类资产数据,比如游戏的种族、等级、经验等等,都可以存储在 Sui 的对象中。Sui 可以使用传统的方法来扩展链上存储,现在更新链上资产的成本要低得多。

这一篇长推到此结束。这些内容维度较高,但并不是很全面。不过,我希望你能通过这些内容加深对 Sui 的了解。