概述
1）Aptos labs 已經解決了DAG BFT中兩個重要的開放問題，大大地減少了延遲，並且首次消除了確定性實際協議中對暫停的需求。總的來說，在無故障情況下將Bullshark的延遲改進了40%，在故障情況下改進了80%。
2）Shoal 是一個框架，通過pipelining and leader reputation增強任何基於 Narwhal 的共識協議（例如，DAG-Rider、Tusk、Bullshark）。流水線通過每輪引入一個錨點來減少 DAG 排序延遲，領導者聲譽通過確保錨點與最快的驗證節點相關聯來進一步改善延遲問題。此外，領導者聲譽使 Shoal 可以利用異步 DAG 構造來消除所有場景中的超時。這允許 Shoal 提供我們命名為普遍響應的屬性，它包含通常需要的Optimistic 響應。
3）我們的技術非常簡單，它涉及到按順序一個接一個地運行底層協議的多個實例。因此，當用Bullshark實例化時，我們得到一群正在進行接力賽的「鯊魚」。
動機
在追求區塊鏈網絡的高性能時，人們一直關注降低通信複雜性。 然而，這種方法並冇有導致吞吐量的顯著提高。 例如，在早期版本的 Diem 中實現的 Hotstuff 僅實現了 3500 TPS，遠遠低於我們實現 100k+ TPS 的目標。
然而，最近的突破源於認識到數據傳播是基於領導者的協議的主要瓶頸，並且它可以從並行化中受益。Narwhal 係統將數據傳播與核心共識邏輯分離，並提出了一種架構，其中所有驗證者同時傳播數據，而共識組件僅訂購較少量的元數據。Narwhal 論文報告了 160,000 TPS 的吞吐量。
在之前的文章中，我們介紹了 Quorum Store。我們的 Narwhal 實現將數據傳播與共識分離，以及我們如何使用它來擴展我們當前的共識協議 Jolteon。Jolteon 是一種基於領導者的協議，結合了 Tendermint 的線性快速路徑和 PBFT 風格的視圖更改，可將 Hotstuff 延遲降低 33%。然而，很明顯，基於領導者的共識協議無法充分利用 Narwhal 的吞吐量潛力。儘管將數據傳播與共識分開，但隨著吞吐量的增加，Hotstuff/Jolteon 的領導者仍然受到限製。
因此，我們決定在 Narwhal DAG 之上部署 Bullshark，一種零通信開銷的共識協議。不幸的是，與 Jolteon 相比，支持 Bullshark 高吞吐量的 DAG 結構帶來了 50% 的延遲代價。
在這篇文章中，我們介紹了 Shoal 如何實現大幅減少 Bullshark 延遲。
DAG-BFT 背景
讓我們從理解這篇文章的相關背景開始。關於 Narwhal 和 Bullshark 的詳細描述請參考 DAG meets BFT 帖子。
Narwhal DAG 中的每個頂點都與一個輪數相關聯。為了進入第 r 輪，驗證者必須首先獲得屬於第 r-1 輪的 n-f 個頂點。每個驗證者每輪可以廣播一個頂點，每個頂點至少引用前一輪的 n-f 個頂點。由於網絡異步性，不同的驗證者可能會在任何時間點觀察到 DAG 的不同本地視圖。下麵是一個可能的局部視圖的圖示：
