Update 你所需要的DAG#3-BullShark.md

你所需要的DAG#3-BullShark.md

@@ -126,6 +126,45 @@ Bullshark 遵循这样的趋势：一旦节点接收到至少 2f + 1 条消息
 3. **垃圾回收判定**  
    如果某轮次的时间戳与当前轮次的时间戳差异超过 3 $\Delta\$，则该轮次会被垃圾回收。这里， $\Delta\$ 表示在GST之后可靠广播一条消息所需的时间。
 
+
+### 性能评估
+
+#### a. **在常规场景下的表现**
+
+- **吞吐量（Throughput）：**  
+  Bullshark 的吞吐量显著高于 Hotstuff，达到 **110,000 tx/sec（10个节点）** 和 **130,000 tx/sec（50个节点）**，是 Hotstuff 吞吐量的 **两倍以上**。  
+  虽然看起来随着委员会规模的增加，吞吐量提升有些反直觉，但原因在于 DAG 的实现没有充分优化资源的使用（网络、磁盘、CPU）。因此，更多的节点通过提高资源的多路复用率，反而提升了性能。
+
+- **延迟（Latency）：**  
+  尽管 Tusk 提供了更高的吞吐量，Bullshark 的卖点在于其低延迟——无论委员会规模大小，延迟都保持在 **约2秒**。  
+  这与 Hotstuff 的延迟相当，主要得益于 Bullshark 能够在每 **2轮 DAG 回合** 中提交一个领导者，而 Tusk 则需要 **4轮回合**。
+
+#### b. **在崩溃故障（Crash-Faults）下的表现**
+
+- **Hotstuff 的表现：**  
+  在存在 **3个故障节点** 时，Hotstuff 的吞吐量下降超过 **10倍**，而延迟则增加了 **15倍**。  
+
+- **Tusk 和 Bullshark 的表现：**  
+  二者在崩溃故障下仍然维持较好的吞吐量表现：  
+  - 基于底层 DAG 的架构，交易的收集和传播即使在存在故障节点时也不会受到严重影响。
+  - 吞吐量的下降主要归因于故障节点的容量损失，而非系统机制问题。  
+  - 在 **3个故障节点** 的情况下，Tusk 和 Bullshark 的吞吐量相较于 Hotstuff 提高了 **10倍**，延迟减少了约 **7倍**。
+
+
+#### c. **在异步条件下的表现**
+
+- **Hotstuff 的局限：**  
+  Hotstuff 在 GST（全局稳定时间）之前无法提供活性保证，并且在面对各种对抗性攻击时，系统吞吐量可能降至 **0**。  
+
+- **Bullshark 的表现：**  
+  Bullshark 的部分同步模型可能会遇到类似的问题：  
+  - 如果领导者的消息被无限期延迟，其他节点会在听到领导者的消息之前超时。  
+  - 为了解决这一问题，Tusk 和 DAG Rider 在 DAG 构造完成后 **不可预测地选举领导者**，使此类攻击变得不可能。  
+
+- **Fallback 模式：**  
+  Bullshark 的回退模式（Fallback Mode）在异步条件下提供了与 Tusk 和 DAG Rider 相同的活性保证，同时在同步条件下不影响性能。  
+  - 在回退模式下，Bullshark 放弃了相较于 Tusk 的延迟优势，以保持在异步条件下的活性。
+
 ### **共识与垃圾回收的一致性**
 
 由于基础的可靠广播机制保证了所有节点对领导者的因果历史达成一致，节点在同意排序某些领导者后，也会一致同意垃圾回收哪些轮次。