引言
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 後會輪替一下位置，讓整個傳輸過程更加隨機去中心化，以增進資安上的安全，並減少單點的負荷和風險。