sui_consensus-Narwhal_and_Tusk

Posted on Edited on

sui - https://github.com/MystenLabs/sui

Narwhal consensus - https://github.com/MystenLabs/narwhal

Narwhal and Tusk consensus paper - https://dl.acm.org/doi/10.1145/3492321.3519594

概要

Narwhal and Tusk拥有一个更好的交易内存池，可靠地分配交易，是高性能分类账的关键推动者。 它应该完全从共识协议中分离出来，让共识只剩下订购小型的固定大小的参考工作。 这导致整个系统的吞吐量在很大程度上不受共识吞吐量的影响。

Narwhal 的设计理念

在本节中，我们将这一基本设计逐步扩展到独角鲸，以（i）在领导者提出块时减少双重传输的需求，以及（ii）在有更多资源可用时实现横向扩展。

  1. 第一步是广播块而不是交易，并让领导者提出一个块的哈希，依靠 Mempool 层提供其完整性保护的内容。 然而，验证者还需要确保哈希代表可用块，要求他们在验证块之前下载它们——在共识算法的关键路径内。
  2. 为确保可用性，作为第二步，持续广播该块，从而生成该块可供下载的证书。领导者提出一个简短的证书，证明该块将可用。但是，每个 Mempool 块必须包含一个证书，如果共识暂时失去活性，那么要提交的证书数量可能会无限增长。
  3. 第三步，添加因果关系，为多个 Mempool 块提出单一证书：Mempool 块包括来自所有验证者的过去 Mempool 块的证书。 因此，证书指的是一个区块及其完整的因果历史。 因此，提议这种固定大小证书的领导者提议对包含其完整历史中的块的序列进行扩展。 这种设计非常节省领导者的带宽，并确保达成共识的延迟会影响延迟，但不会影响平均吞吐量——因为内存池块会继续产生并最终提交。 尽管如此，仍然存在两个问题：（i）一个非常快的验证器可能会通过高速生成块来迫使其他人执行大量下载； (ii) 诚实的验证者可能没有足够的带宽与他人分享他们的区块——导致潜在的审查。
  4. 第四步通过对区块创建率施加限制来提供链质量。来自验证者的每个区块都包含一个轮数，并且必须包含来自上一轮的证书的法定人数才能有效。结果，一小部分诚实验证者的区块被包含在任何提案中。此外，在一些诚实的人结束上一轮之前，验证人无法进入内存池轮次，从而防止假交易泛滥。因此，Narwhal 提供了共识层的抗审查性（如 HoneyBadger BFT 中所定义），而无需使用任何额外的机制，例如阈值加密。因此，Narwhal-Hotstuff 系统是唯一提供抗审查性的基于部分同步仲裁的协议。对手无法杀死领导人，因为它不喜欢该提案，因为所有提案都包含至少 50% 的诚实交易，即使是来自拜占庭领导人的交易。
  5. 最后的第五个设计步骤是启用横向扩展。每个验证者的多个工作（worker）机器可以共享 Mempool 子块，而不是让单个机器创建 Mempool 块，称为批次-batches。一个主工作者在 Mempool 主块中集成对它们的引用。这使验证者能够将大量计算、存储和网络资源用于共享事务的任务——允许准线性扩展。

Narwhal 的设计核心

  1. The Narwhal Mempool - Narwhal 交易池

  1. 使用 Narwhal 达成共识

Narwhal-Hotstuff 算法/机制中，leader 领导者可以提议一个或多个在 Narwhal 创建的可用性证书，而不是提议一个交易块。提交时，证书的完整未提交因果历史被确定地排序和提交。Narwhal 保证在给定证书的情况下，所有验证者都会看到相同的因果历史，这本身就是区块上的 DAG。因此，该 DAG 上的任何确定性规则都会导致所有验证者的区块总排序相同，从而达成共识。此外，由于 Narwhal 的可用性属性，所有已提交的块都可以被检索和交易排序。

与直接发送交易块相比，使用独角鲸的领导者有很多优势。即使在没有失败的情况下，广播交易的领导者也会导致资源使用不均：轮领导者必须使用大量的带宽，而其他每个验证者的带宽都没有得到充分利用。相比之下，Narwhal 可确保始终高效、均匀地共享批量交易信息，从而提高网络利用率和吞吐量。

最终同步的共识协议不能在异步期间或领导者是拜占庭时提供正确共识。因此，在简单的内存池实现中，总体共识吞吐量在此期间变为零。相比之下，即使在异步网络下，Narwhal 也会继续共享区块并形成可用性证书，因此区块始终以最大吞吐量进行认证。一旦共识协议设法提交摘要-digest hash，验证者也会提交其因果历史，在异步期间没有间隙。尽管如此，最终同步的协议在异步期间仍然会失去正确共识，从而导致延迟增加。 我们展示了如何用 Tusk 克服这个问题。

个人观点

  1. Narwhal 设计 Mempool，从架构角度来看，实际上是数据提交过程中的一个阶段，配合上 Hotstuff 的3阶段数据提交，可以认为Narwhal 实际上是一个 4 阶段提交的共识机制。在实际上线mainnet之后，理论上比 tendermint 的 per transaction delay time 要长；吞吐量会大幅增长。目前Cosmos Hub区块链上共有342个验证者，有效验证人150，平均区块时间7.29秒，理论上 10,000 TPS。
  2. 对有人提出，将 Narwhal + EVM 的观点，本人并不认同：因为在 EVM 中，Smart Contract 之间是可以调用的，但是 Narwhal 的 Mempool 无法认知其关联关系，导致共识机制无法正确地对交易进行排序。而 Move 在变成语言层面对智能合约的状态进行隔离，不存在上述 EVM 中的问题。

参考

Move 相比 Solidity 的三大优势 - https://mirror.xyz/snapfingersdao.eth/0MExjukNkgMfaIl5FiI87DeCfaeONy_ameYULkiAeNA