https://medium.com/@zkrush/what-is-aleobft-1b8dde0c8739
BFT（拜占庭容错）是分布式系统中用于处理节点故障和恶意攻击的共识算法。其目标是在存在节点故障和恶意攻击的情况下确保系统的安全性和可用性。BFT 共识算法的基本思想是选择一组节点共同维护系统状态，并使用复杂的协议保证节点间信息的一致性和正确性。在节点之间达成共识之前，所有节点必须就当前状态达成一致，以确保系统的正确性和安全性。
但什么是 AleoBFT？Aleo 即将进入 Testnet 3 的第三阶段，这一阶段的主要目标是推出 PoS 并测试 Aleo 的共识算法 AleoBFT。在 snarkOS 存储库中，我们可以看到一个名为 “enter_bullshark” 的新分支，该分支目前正在为 AleoBFT 开发。
分支名称“bullshark”表明，AleoBFT 实际上是基于 Sui 的 Narwhal & Bullshark 共识算法的实现。
独角鲸和牛鲨
Narwhal 和 Bullshark 来自两篇论文：
· Narwhal & Tusk（EuroSys 2022 最佳论文奖）[G. Danezis, E. Kokoris-Kogias, A. Sonnino, A. Spiegelman]
· Bullshark（出现在 CCS 2022）[A. Spiegelman, N. Giridharan, A. Sonnino, E. Kokoris-Kogias]
Narwhal & Tusk论文启发式地将传统拜占庭容错共识算法中交易传播和交易排序的处理分开。这不仅允许验证者线性扩展以提高吞吐量并减少整个网络的延迟，而且还通过将共识协议抽象为 Narwhal 并结合其他共识算法（例如论文中提到的 Narwhal-Hotstuff）来提高可扩展性。
Narwhal是一种DAG内存池抽象，将整个验证者网络抽象成一个DAG内存池，对用户屏蔽所有与节点传播和通信相关的实现细节，并根据交易客户端的请求在DAG中生成顶点或一批交易。
Tusk 是 Narwhal 组件中的内部共识协议。在 Sui 的实现中，如果没有指定外部共识协议，则会启动内部共识（Tusk/Bullshark）。在 Narwhal 生成数轮顶点后，将使用随机共享硬币（一种神奇的分布式密码学）从多个初选中随机选择一个领导者，并提交该轮领导者的顶点。
Bullshark 是 Tusk 的改进版，主要是提高了它的公平性。在同步网络模型中，它确保诚实节点之间的所有交易都可以打包到链中，从而减少网络延迟。下文提到的共识协议均指 Bullshark。
AleoBFT 中的 DAG 是什么？
AleoBFT，或 Narwhal & Bullshark，是一种基于 DAG 的共识算法。但什么是 DAG，它在共识中扮演什么角色？
首先，DAG代表有向无环图。在 Narwhal 中，每个验证者都尝试为每一轮生成一个顶点，并且每个顶点都连接到上一轮的顶点。具体执行过程如下：
1.更新到本轮；
2. 每个验证者根据收到的交易生成一个区块；
3.广播区块并收集其他验证者的签名；
4、根据签名数量（num > 2f +1）生成证书，并引用自生成块的BlockDigest；
5、如果本轮收集到的证书超过2f+1个，则强制进入下一轮。
在这种情况下，(Block, Certificate) 元组是 DAG 中的顶点。重复这种方法，直到整个网络产生一个有向无环图（DAG）。一旦你在网络中有了一个顶点，你就可以使用边缘来发现上一轮的父顶点。父母顶点然后可以找到它的父母。结果，当整个网络就一个顶点达成一致时，它也同意与该顶点相关的所有因果关系，最终网络实现一致性。
那么共识算法如何在DAG中提交一个顶点及其因果关系呢？
在Bullshark中，通过神奇的分布式加密技术，使用公平的全局硬币在偶数轮中选择领导者，并且该轮的领导者块被用作锚点(等待提交的顶点)。图中所有的绿色标记都是锚点。当验证器成为领导者并锚定当前点(顶点)时，它会返回获取与该点(顶点)有因果关系的所有未提交点(并非全部在实际实现中)，并将它们打包到子dag中。然后，在下一个奇数轮中，对子dag进行投票。投票规则是，如果这一轮的主播和前一轮的主播有优势，就进行投票。如果投票数超过f+1，则该锚被提交。在下面的图中，锚A1有一票，少于f+1，所以它不会在第1轮中提交。在第3轮中，锚A2有3票，大于f+1，并且由于A1与A2存在因果关系，因此A1和A2都将被提交。
当然，为了简单起见，这里没有提及许多细节。例如，引入了GC(垃圾收集器)和弱链路的概念，这也减少了延迟，提高了网络的公平性。
代码分析
回到最新的AleoBFT代码库，因为Sui很好地抽象和解耦了共识模块，Aleo可以直接使用它，只需要做一些微小的修改。在这种情况下，我们忽略了Narwhal 的细节，而是将其视为一个以预定间隔产生共识数据的黑匣子。
“Advance_to_next_block”的整个过程如下:
1. 客户端将事务发送到验证器的工作节点。
2. 工作程序组装事务并将它们发送到主批摘要。
3.主节点根据批处理摘要为新一轮生成一个块。
4. 将区块发送给其他验证者，从而获得 2f+1 sig 证书。
5. 如果此验证器成为领导者，则验证器调用 process_certificate 生成 Committed SubDag 数组。
6. 基于Committed SubDag，从内存池中取出the_payload，形成Consensus Output。
7. 根据executor trait的外部实现，处理共识输出。Aleo 在这部分嵌入了状态机更新的逻辑，将账本推进到下一个区块。
8. 验证者广播新区块，其他验证者检查后加入账本。
未来展望
AleoBFT的开发正在如火如荼的进行中，由于采用了既定的解决方案，应该会在不久的将来发布到测试网进行测试。代码库中也有 Aleo 团队测试的证据，例如用于测试的测试脚本和本地配置文件。但是，还有很多需要解决的问题并没有在代码中体现出来。例如，
1、处理客户端发送的交易的代码还不完整；
2. 未来如何处理“过时”的信标，因为区块的生产已经由验证者完成；
3. 将现有代币整合到 Narwhal 的质押中；
4.大量的稳定性测试。
总的来说，考虑到即将到来的第 3 阶段，共识模块的完成并不遥远。如果一切顺利（按照 Aleo 团队的设计），共识应该在1-2 周内在测试网上启用，如果有延误，应该在一个月之内。
在 Sui 的最新推文中，我们了解到 Sui 的共识算法可以实现惊人的 30万 TPS 和 480ms 延迟。这让我们对 Aleo 的期望更加兴奋，它也使用 Narwhal & Bullshark 算法和 ZK。作为第一条真正意义上的隐私保护公链，Aleo的上线可能会带来远超我们想象的宏大叙事。
