# Solana 玩家：一文速通 BSC 網絡篇（一）— 交易廣播鏈路

> 習慣Solana確定性SWQoS的開發者，如何應對BSC基於公共Mempool和Gossip協議的交易傳播機制

Source: https://blockrazor.io/zh/blog/20251031guidetobscnetwork1/  
Updated: 2025-10-31  
Author: BlockRazor  
Language: zh-Hant

---

![面向 Solana 開發者的 BSC 交易傳播指南](/blogs/images/20251031guidetobscnetwork1cover.png)

歡迎來到 BNB Smart Chain (BSC)！作為一名經驗豐富的 Solana 開發者，您習慣了 QUIC 協議、Stake-Weighted QoS (SWQoS)、Leader 輪換以及無公共 Mempool 的交易環境。而 BSC，作為一條 EVM 兼容鏈，其交易從發起到被打包的鏈路機制截然不同。

本節將聚焦於 **交易廣播鏈路**，通過與 Solana 的對比，詳細拆解 BSC 的交易如何被網絡接收、傳播並最終打包。

### **1. BSC 交易廣播詳解：Mempool 與 Gossip 協議**

BSC 的交易傳播機制與 Ethereum 類似，核心依賴於一個去中心化的 **公共內存池 (Mempool)** 和 **P2P Gossip 協議**。這個過程不是像 Solana 那樣將交易「推送」給 Leader，而是一個在網絡中「擴散」和「拉取」的過程。

### 1.1 步驟 1：節點發現與連接建立 (P2P 網絡)

在 Solana 中，您的 RPC 節點已經通過 Leader Schedule 知道了 Leader 的地址。而在 BSC 中，一個節點（包括 RPC 節點）必須先「找到」網絡中的其他節點（Peers）。

1. **引導：** 新節點啟動時，會聯繫硬編碼的 **引導節點 (bootnodes)**。
2. **發現：** 節點向 Bootnode 發送 `PING` 請求。Bootnode 回復 `PONG`，並提供一個它所知道的**附近節點列表**。
3. **連接：** 節點使用 **RLPx 協議** 與這些 Peers 建立加密且經過身份驗證的 TCP 通道，交換節點 ID、端口等信息，正式成為對等節點 。

這就構建了一個去中心化的 P2P 網絡，為交易傳播奠定了基礎。

### 1.2 步驟 2：交易進入本地 Mempool

1. **用戶提交：** 您（或您的應用）將簽名的交易發送到連接的 RPC 節點（全節點）。
2. **本地驗證：** RPC 節點會立即進行一系列驗證（與 Solana RPC 的 *pre-flight check* 類似），檢查：
    - 簽名是否有效？
    - Nonce 是否正確（是否為賬戶的下一個 Nonce）？
    - Gas Limit 是否在區塊限制內？
    - 賬戶餘額是否足夠支付 `Gas Limit * Gas Price`？
3. **進入本地 Mempool：** 驗證通過後，該交易被放入這個 RPC 節點**自己的本地 Mempool** (待處理交易池)。

### 1.3 步驟 3：Gossip 傳播（「哈希廣播-拉取」模式）

這是與 Solana 機制**差異最大**的地方。Solana RPC 會將交易打包（PacketBatch）並「推送」給 Leader TPU。而在 BSC 中：

1. **廣播哈希 ：** 當節點的 Mempool 收到一筆新交易時，它**不會**立即廣播完整的交易。相反，它會通過 **Wire Protocol** 向其隨機選擇的 √N個 Peers 廣播一個 `NewPooledTransactionHashes` 消息（一個**哈希列表**）。
2. **Peers 拉取 ：** 接收到哈希列表的 Peers，會檢查自己的 Mempool。如果發現某個哈希是自己沒有的，它會向發送方發送 `GetPooledTransactions` 消息，**主動拉取**完整的交易數據。
3. **「洪泛」擴散 (Flooding)：** 收到完整交易的 Peer，會對其進行本地驗證（同 1.2 步），然後將其加入自己的 Mempool，並**重複步驟 1**——向它自己的 Peers 廣播這個交易的哈希。

交易就是通過這種「哈希廣播-拉取」的方式，在網絡中像「洪水」一樣擴散 (flooding)，最終確保網絡中的所有節點（包括驗證者）都能在其 Mempool 中看到這筆交易。

### **2. BSC 交易排序規則（原生機制）**

在 Solana 中，交易排序主要基於**CU Price**和賬戶鎖競爭。在 BSC 中，當驗證者從 Mempool 中選擇交易構建區塊時（在 PBS 機制引入前或 Builder 未介入時），其原生排序規則嚴格遵循 EVM 規範：

1. **Nonce**：同一賬戶的交易必須嚴格按 **Nonce 升序** 執行。這是 EVM 強制的數據一致性規則。
2. **GasPrice** ：在 Nonce 排序的基礎上，跨賬戶的交易按 **Gas Price 降序** 優先。這類似於 Solana 中的**CU Price**，高 Gas Price 的交易會被優先打包，以最大化驗證者收益。
3. **ArrivalTime**：如果兩筆不同賬戶的交易 **Gas Price** 相同，則**先到達**驗證者 Mempool 的交易優先。

### **3. 與 Solana 交易鏈路的對比**

為了幫您更直觀地理解，我們來回顧一下 Solana 的鏈路：

- **非 SWQoS 鏈路 ：** 交易被推送到 Leader 的 `tpu` 端口，這裡有約 500 個開放連接，無質押加權，先到先得，容易丟包。
- **SWQoS 鏈路 (Stake-Weighted QoS)：** 交易通過 Staked Validator 轉發，進入 Leader 的 `tpu` 端口（約 2000 個**質押加權**連接）。高質押節點獲得更多帶寬，上鏈確定性高。

現在，我們來總結 BSC 與 Solana 的核心差異：

![BSC 與 Solana 交易傳播機制對比](/blogs/images/20251031guidetobscnetwork1tablezh.png)

### **4. 給 Solana 開發者的新認知**

對於習慣了 Solana **確定性轉發 (SWQoS)** 的開發者來說，理解 BSC 鏈路的核心要點是：

1. **不再是「Leader 直達」：** 您的交易不再是直接發送給 Leader，而是需要在P2P網絡中廣播，等待被所有驗證者「發現」和「拉取」。
2. **高不確定性：** 您的交易從提交到被驗證者收錄的時間，高度依賴 P2P 網絡的拓撲結構和傳播速度，這帶來了**更高的上鏈不確定性**和**延遲**。
3. **第三方解決方案至關重要：** 就像 Solana 的 SWQoS 鏈路可以顯著提高上鏈速度一樣，在 BSC 上，**BlockRazor** 等[第三方服務](https://docs.blockrazor.io/tc/transaction-submission/transaction-sending/bsc/broadcast-tx)正是通過建立類似於 SWQoS 的**低延遲直連渠道**（直接橋接到驗證者節點），來解決原生 P2P 廣播帶來的延遲和丟包問題。若您追求極致的交易速度和成功率，應考慮使用這些服務。

---

現在您已經對 BSC 的交易廣播鏈路有了初步的了解，下篇文章中我們將進一步介紹BSC 採取的 **MEV 鏈路（PBS 機制）** 與 Solana Jito 的差異。另外，我們誠摯歡迎各位用戶加入我們的[Discord頻道](https://discord.gg/V89ENcvKVR)，共同探討相關議題。