我們已經瞭解了 BSC 的交易如何通過內存池（Mempool）傳播（第一部分），以及 MEV 區塊如何通過 PBS 競價產生（第二部分）。現在，我們來看最後一步：這個最終確定的區塊是如何廣播給全網的？

在 Solana 上，您習慣了 Turbine 協議——一個基於 UDP、將區塊「切碎」並通過 Stake 加權樹狀結構以 $O(\log n)$ 延遲高效廣播的機制。

BSC 則完全不同，它採用的是一種更接近傳統 EVM 鏈的 TCP Gossip 協議，廣播的是完整區塊。

1. BSC 區塊廣播機制詳解 (Full Block Gossip)

當一個驗證者（Proposer）選定區塊後，它會立即開始廣播，這個過程主要依賴 TCP Gossip 協議。

1. 準備與封印 (Seal)： 驗證者對區塊進行最終計算（如封印雜湊 Seal Hash），附加其 BLS 簽名，並將區塊寫入本地節點。
2. 選擇性全區塊廣播 (Propagate Block)： 驗證者不會立即向所有 Peers 廣播完整區塊。
   • 它會選擇一個子集（通常是 $\sqrt{N}$ 個 Peers）並透過 TCP 發送完整的、RLP 編碼的區塊體（BlockAnnouncement 訊息）。
3. 哈希公告廣播 (Announce Hash)： 對於網絡中剩餘的 Peers，驗證者只發送區塊哈希（BlockHashAnnouncement 訊息）。
   • 這是一種帶寬優化策略，避免網絡擁塞。
4. Peers 接收與鏈式轉發：
   • 收到全區塊的 Peers： 立即進行驗證。如果有效，它們會重複步驟 2 和 3，將區塊（或哈希）轉發給它們自己的 Peers。
   • 收到哈希的 Peers： 如果自己沒有這個區塊，會向發送方請求拉取 (pull) 完整的區塊。
5. 投票與最終性 (Finality)： 網絡中其他活躍驗證者收到並驗證該區塊後，會生成自己的 BLS 簽名投票（broadcastVote），並通過 Gossip 協議廣播這些投票。
   • 當一個區塊獲得了 2/3 的驗證者投票（Justification），它就接近最終確認。當它的子區塊也被 Justified 後，該區塊即被視為 Finalized（不可逆轉）。

2. 與 Solana Turbine 機制的對比

3. 給 Solana 交易者的核心啟示：信號源的根本差異

這兩種截然不同的廣播模式，為交易者帶來了完全不同的狀態更新機制和信號源。

在 Solana 中： 您的狀態更新強依賴於 Shreds。

• 您透過預執行 Shreds 來更新世界狀態，再透過 geyser 插件進行交易訂閱，或者透過工具進行 deshred 獲得交易原文。
• 由於沒有公共 Mempool，Shreds 既是「區塊廣播」，也是您能獲取的最早的「交易信號」。您的競爭優勢來自於多快能解析 Shreds。

在 BSC 中： 您的信號源是一分為二的，您必須同時監控兩個關鍵信號：

• Pending 信號（「即將發生什麼？」）：
  • 來源： 公共 Mempool（NewPooledTransactionHashes 廣播）。
  • 意義： 這是在區塊被確認前的信號。高速獲取這些 pending 交易，是您建構交易策略的基礎。
• Confirmation 信號（「已經發生了什麼？」）：
  • 來源： 區塊廣播（BlockAnnouncement 廣播）。
  • 意義： 這是最終狀態的確認。當您收到這個完整區塊時，您可以 100% 確認交易的執行結果，並立即觸發您的下一筆交易（例如，為下一個區塊的競爭做準備）。

4. 總結：BSC 的雙重競速

對於習慣了 Solana 「單一 Shred 信號源」 的開發者而言，BSC 的策略是雙重的：

• 競速 1 (Mempool)： 您需要以最低延遲接入 P2P 網絡，以便在其他人之前捕獲 pending 交易。
• 競速 2 (Blocks)： 您需要與驗證者建立最直接的網絡連接，以便在其他人之前接收到已確認的區塊。

在 BSC 上，如果您的 Mempool 信號比對手慢，您就無法建構最優的 Bundle；如果您的區塊確認信號比對手慢，您在下一個區塊的競爭中就會失去先機。這就是為什麼在 BSC 生態中，像 BlockRazor 這樣提供高速👉 P2P 交易和區塊廣播的專業網絡服務至關重要的原因。

本系列文章將持續為開發者提供 BSC 機制解讀、研發建議及最新熱點資訊。我們誠摯歡迎您加入我們的 Discord 頻道，共同探討相關議題，助力您更快熟悉 BSC 平台。