Turbine就是一個強化版的八卦網路，當領導者把他認為對的事做完後就會昭告天下，使用 Turbine 網路一傳十、十傳百的讓所有驗證節點知道，並讓他們投票表決是否同意這些事情是正確的。
讀完本篇，您將會了解 Solana 網路中區塊是如何在驗證者之間傳遞，傳遞過程中可能會遇到什麼問題，又有何解決方法？
提醒讀者：如果您尚未閱讀過或想先了解 Solana 的基本運作流程，建議先參考 **由 Transaction 的生命週期看 Solana 的底層架構 ，**這將有助於您更好地理解本篇深入探討的技術細節。
在領導者更新完 bank 狀態後，會把 entry 分成許多的 shreds（此動作稱為 shredding）， 每個 shred 儲存著 transaction 的部分資訊（最大1280 bytes），並透過 UDP 協議傳送給底下的 root，再由 root 往下以「Turbine Tree」的樹狀結構傳給其他的驗證者。由於 UDP 協議會有嚴重的掉包問題，所以在 shreds 傳輸過程前後需要使用一些資料復原的方法，如此一來就算在傳輸過程中遺失了一部分的 shreds，還是可以透過資料復原技術還原回當初被分解的 entry。
在 Solana 中使用的資料復原技術是 Reed-Solomon Erasure coding，簡單來說他就傳了多一倍的備份資料，這樣即使在傳輸過程中掉了一半的包，還是可以用另一半來復原完整的資料。所以驗證者在收 shreds 時，會將 64 個 shreds 組成一個 forward error collection (FEC) batch。這一包 FEC 由 32 個 data shreds 加 32 個 recovery shreds 組成，從名字就可以看出如果掉了一半的 shreds 還是可以透過密碼學的方式解回原本的 entry。
目前 Turbine Tree 的 fanout = 200，通常會有二至三層 (hop) 因此一棵樹約由 40000 個以上的節點組成。且這些節點在收集完一個 FEC batch 後會輪替一下位置，讓整個傳輸過程更加隨機去中心化，以增進資安上的安全，並減少單點的負荷和風險。