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