本文总结了 Sui 与现有区块链的比较，旨在帮助 Sui 的潜在使用者来决定 Sui 是否适合他们的场景。有关 Sui 架构的介绍，请参见 Sui 的工作原理《Sui 区块链概览：主要功能和设计选择！》。
以下是 Sui 的主要特点：
-
因果顺序 vs 总顺序可实现大规模并行执行
-
Sui 版本的 Move 变体及其以对象（object）为中心的数据模型使可组合对象/NFT 成为可能
-
面向区块链的 Move 编程语言简化了开发者体验
传统区块链
传统的区块链验证人共同构建一个共享累加器来表示区块链的状态，一个随着时间添加增量的链，这个增量称为区块。在提供确定性的最终性的区块链中，验证者每次想要对区块链进行增量添加时，即区块提案，他们都会对提案进行排序。该协议让他们就链的当前状态、提议的增量是否有效以及新添加后的链的状态达成一致。
这种随着时间的推移保持公共状态的方法在过去 14 年取得了实际成功，它使用了过去 50 年的研究理论，即拜占庭容错分布式系统。
然而它本质上是连续的：链的增量（区块）是一次添加一个，就像串上的珍珠。在实践中，这种方法会暂停交易的涌入（通常存储在“内存池”中），同时考虑当前块。
Sui 验证新交易的方法
许多交易与区块链状态的其他部分没有复杂的相互依赖性。通常，金融用户只想将资产发送给接收者，而衡量这种简单交易是否被接受所需的唯一数据是发送者地址的全新视图（fresh view）。因此，Sui 采取了只锁定相关数据或“停止世界”而不是整个链的方法。在这种情况下，发送方的地址，一次只能发送一个交易。
Sui 使用对象模型并利用 Move 的强大所有权模型，进一步将这种方法扩展到更多涉及的交易，这些交易可能明确依赖于其发送者控制下的多个元素。通过要求明确的依赖关系，Sui 将“多通道”方法应用于交易验证，确保那些独立的交易流可以不受其他交易的阻碍进行。
这并不意味着 Sui 作为一个平台从不对交易进行排序，或者它允许所有者仅影响他们拥有的对象的缩影。Sui 还以严格的、共识有序的方式处理对某些共享状态有影响的交易。它们只是不是默认的用例。有关 Narwhal 和 Bullshark 共识引擎的详细信息，请参阅最新共识部分。https://docs.sui.io/learn/architecture/consensus
交易提交的协作方法
Sui 单独验证交易，而不是在传统区块中批量处理。这种方法的主要优点是低延迟；每笔成功的交易都会迅速获得一份最终证明，向任何人证明该交易将由 Sui 网络处理。
但是提交交易的过程有点复杂。网络上会发生更多的工作。（但随着带宽变得越来越便宜，这不再是一个问题。）虽然通常的区块链可以在一劳永逸的模式下接受来自同一作者的一堆交易，但 Sui 交易提交遵循以下步骤：
-
发件人向所有 Sui 验证者广播交易。
-
Sui 验证者给发送者发送这个交易的个人投票。
-
每个投票都有一定的权重，因为每个验证者都有基于 PoS 规则的权重。
-
发送者将这些选票中的多数选票收集到一个证书中，并将其广播给所有 Sui 验证者，从而确保最终性，或保证交易不会被丢弃（撤销）。
-
可选地，发送者收集详细说明交易效果的证书。
虽然这些步骤需要发送者更多，但有效地执行它们仍然可以产生具有最小延迟的最终性加密证明。除了制作原始交易本身之外，交易的会话管理（session management）不需要访问任何私钥，并且可以委托给第三方。
状态的不同方法
因为 Sui 专注于管理特定对象而不是单个状态聚合，所以它还以独特的方式报告它们：
-
Sui 中的每个对象都有一个唯一的版本号。
-
每个新版本都是从可能涉及多个依赖项的交易创建的，这些依赖项本身就是版本化对象。
因此，一个 Sui 验证者 —— 或任何其他具有状态副本的验证者 —— 可以展示一个对象的因果历史，显示其自创世以来的历史。Sui 明确打赌，在许多情况下，因果历史与另一个对象的因果历史的顺序是不相关的。在与此信息相关的少数情况下，Sui 在数据中明确说明了这种关系。
因果顺序与总顺序
与大多数现有的区块链系统不同，Sui 并不总是对客户端提交的交易施加总顺序，共享对象（shared objects）是例外。相反，许多交易是因果排序的 —— 如果交易 T1 产生的输出对象 O1 用作交易 T2 中的输入对象，则验证者必须在执行 T2 之前执行 T1。请注意，T2 不需要直接使用这些对象来存在因果关系 —— 例如，T1 可能会产生输出对象，然后由 T3 使用，而 T2 可能会使用 T3 的输出对象。然而，没有因果关系的交易可以由 Sui 验证者以任何顺序处理。
最先进的共识
Narwhal 和 Bullshark 代表了几十年来多提议者、高吞吐量共识算法工作的最新变体，该算法在 WAN 上达到每秒超过 130,000 笔交易的吞吐量，具有生产加密、永久存储和横向扩展的主工作机的架构。
Narwhal 内存池提供了一个高吞吐量的数据可用性引擎和一个可扩展的架构，将磁盘 I/O 和网络需求分配给多个工作机。Bullshark 是一种零消息开销共识算法，利用了图形遍历。
Sui 擅长的地方
这里总结了 Sui 相对于传统区块链的主要优势。
1. 高性能
Sui 的主要亮点是其前所未有的性能表现。以下要点总结了 Sui 相对于传统区块链的主要性能优势：
-
Sui 放弃了许多交易的共识，而其他区块链则是完全按照顺序。因果排序交易允许 Sui 大规模并行执行许多交易；这减少了延迟并允许验证者利用他们所有的 CPU 内核。
-
Sui 将复杂性推到了边缘：客户端参与了许多协议步骤。这最大限度地减少了验证者之间的交互，并使它们的代码更简单、更高效。Sui 始终提供将大部分客户端工作负载卸载到 Sui 网关服务的可能性，以获得更好的用户体验。相比之下，传统区块链遵循“一劳永逸”模式，客户监监视区块链状态以评估其交易提交的成功与否。
-
Sui 以网络速度运行，无需等待协议步骤之间的系统超时。当网络良好且未受到攻击时，这会显着减少延迟。相比之下，许多传统区块链（包括大多数基于工作量证明的区块链）的安全性需要在提交交易之前等待预定义的超时。
-
Sui 可以利用增加每个验证者的机器来提高其性能。传统的区块链通常设计为在每个验证者的单台机器上运行（甚至在单个 CPU 上）。
2. 故障下的性能
Sui 运行一个无领导者协议来处理简单的交易（即只包含拥有对象 owned objects）。因此，有缺陷的验证者不会以任何显着的方式影响性能。对于涉及共享对象的交易，Sui 采用了最先进的共识协议，不需要视图更改子协议，因此只会出现轻微的性能下降。相比之下，大多数基于领导者的区块链甚至经历了单个验证者的崩溃，它们的吞吐量下降并且延迟增加（通常超过一个数量级）。
3. 安全假设
与许多传统区块链相反，Sui 并未对网络做出强同步假设。这意味着 Sui 在恶劣的网络条件（甚至非常糟糕）、网络分裂/分区，甚至针对验证者的强大 DoS 攻击下仍能保持其安全属性。对同步区块链（即大多数基于工作量证明的区块链）的持续网络攻击可能导致资源双花和死锁。
4. 高效的本地读取操作
Sui 的读取过程与其他区块链有很大不同。只对少数对象及其历史感兴趣的用户以低粒度和低延迟执行经过身份验证的读取。Sui 从创世开始创建了一个狭窄的对象家族树，允许它只读与交易发送者相关的对象。需要系统全局视图（例如，审计系统）的用户可以利用检查点来提高性能。
在传统的区块链中，families 是相互排序的，以完全排序交易。然后，这需要查询大量 blob 以获取所需的精确信息。因此，磁盘 I/O 成为性能瓶颈，因此一些区块链现在需要在其验证者上安装 SSD 驱动器。
5. 更轻松的开发者体验
Sui 为开发者提供了以下好处：
-
Move 和以对象为中心的数据模型（启用可组合对象/NFT）
-
以资产为中心的编程模型
-
更轻松的开发者体验
工程权衡
该节介绍 Sui 相对于传统区块链的主要缺点。
1. 设计复杂度
传统区块链只需要实现一个共识协议，而 Sui 需要两个协议：（i）基于拜占庭一致广播的协议来处理简单的交易，以及（ii）共识协议来处理与共享对象的交易。这意味着 Sui 团队需要维护一个更大的代码库。
涉及共享对象的交易在将其提交到共识协议之前需要一点开销（添加两个额外的往返行程 - 使用 Sui 网关服务的连接良好的客户端需要 200 毫秒）。这种开销是安全地组合上述两种协议所必需的。其他区块链可以直接将交易提交给共识协议。请注意，即使有此开销，共享对象交易的最终确定性仍在 2-3 秒范围内。
在 Sui 中构建高效的同步器比在传统区块链中更难。同步器子协议允许验证者通过共享数据来相互更新，它允许较慢的验证者赶上。为传统区块链构建高效的同步器并非易事，但仍然比 Sui 简单。
2. 简单情况下的顺序写入
传统区块链完全对所有客户交易进行相互排序。这种设计需要在验证者之间达成共识，这是有效但缓慢的。
如前几节所述，Sui 放弃了许多交易的共识以减少延迟。通过这种方式，Sui 启用了多通道处理并消除了线头阻塞（head-of-line blocking）。所有其他交易不再需要在单个通道中等待第一个交易的增量完成。Sui 为每笔交易提供适当宽度的通道。简单的交易只需要查看发件人地址，大大提高了系统的容量。
对于这些简单的交易，允许对发送者进行线头阻塞的缺点是发送者一次只能发送一个交易。因此，交易必须迅速完成。
3. 复杂的总查询
与传统区块链相比，Sui 可以使总查询更加困难，因为它并不总是强加交易的总顺序。就本地读取而言，总查询相当少见（见上文），但在某些情况下很有用。例如，新的验证者加入网络并需要将总状态下载到磁盘，或者审计员希望审计整个区块链。
Sui 通过检查点缓解了这种情况。每次将增量添加到由认证交易产生的区块链时，都会建立一个检查点。检查点的工作方式很像预写日志，它在程序完全执行之前存储状态。该程序中的调用代表区块链中的智能合约。检查点不仅包含交易，还包含交易前后对区块链状态的承诺。
Sui 使用在 epoch 变化时到达的状态承诺。Sui 需要来自多个验证者的单一答案，并利用附属协议来派生代表区块链状态的哈希值。该协议消耗的带宽很少，并且不会阻碍交易的摄取。验证者在每个 epoch 变化时产生检查点。Sui 要求验证者也更频繁地生成检查点。因此，用户可以使用这些检查点来审核区块链。
总结
总之，Sui 在不太简单的用例中以一些复杂性为代价提供了许多性能和可用性增益。直接发件人交易在 Sui 中表现出色。复杂的智能合约可能会受益于共享对象，其中多个用户可以改变这些对象（遵循智能合约特定规则）。在这种情况下，Sui 使用共识协议对所有涉及共享对象的交易进行完全排序。
Sui 使用基于 Narwhal 和 Bullshark 的新型同行评审共识协议，提供基于 DAG 的内存池和高效的拜占庭容错 (BFT) 共识。这在性能和稳定性方面都是最先进的。
原文：https://docs.sui.io/learn/sui-compared
翻译：Suiverse 社区