解讀Solana BAM區塊組裝市場：當速度不再是唯一的追求

Solana 已經足夠快，交易量足夠大。然後就真的“足夠”了麼？

當我們審視那些交易時，有個問題一直存在：這些交易真的都在創造價值嗎？

Solana 大量的交易並非來自真實交易需求，而是高頻套利者利用毫秒級信息差獲取利潤。 這些"有毒交易者"（Toxic-takers）利用技術優勢，在做市商（Maker）即將撤單時，增加 Gas，讓自己的交易先打包，完成套利，使做市商承受損失。 爲了彌補損失，做市商只能擴大買賣價差。

最終，普通用戶爲此買單。 Solana 始終有一個在鏈上實現訂單薄，取代 CEX 的夢想。但這樣一來，"有毒交易者"便成爲了實現夢想的障礙。 這就是 Solana 面臨的新挑戰：交易量≠流動性。真正健康的市場需要的不是更多的交易，而是更好的交易。

如何能夠剔除有毒交易，更好地保護流動性？

當前系統中，吃單者（Takers）因爲 Solana 共識週期性拍賣機制，而享有實際優先權，使惡意 MEV 影響市場公平性。

如何理解？

在Solana當前共識中，每個時間段 Slot 內，交易按照支付的優先 Gas 費用排序，誰出價高，誰的交易就先執行。這個拍賣是週期性的，每 400毫秒一個 Slot。

在此過程中，做市商需要頻繁調整報價，撤單、重新掛單。市場價格變化時需要立即更新。

而吃單者（Taker）特別是高頻套利者，則監控價格差異，發現機會就立即成交。 所以，套利者可以通過支付更高費用來搶在撤單之前成交。導致做市商經常被"狙擊"，承擔損失。

對訂單薄 DEX 來說，理想的排序應該是，隨着價格波動，先執行所有撤單，再執行新掛單，最後執行成交。這是目前 Solana 共識在微觀層面做不到的。

而在預言機報價層面也是一樣，理想情況是，先更新預言機價格，再執行依賴該價格的交易。 但在目前的 400毫秒間隔內，行情可能因劇烈波動，導致成交時仍按原先價格成交。

對借貸協議來說，最好是先補保證金，再來進行清算。

所以，最好有一種方式，能讓不同的協議，按照需求對交易排序，也就是 Solana 一直在強調的 ACE 應用控制執行（Application-Controlled Execution）。

BAM（Block Assembly Marketplace，區塊組裝市場）正是 Solana 的答案。

BAM 在 Solana 鏈上應用與主網之間，構建了一個排序層，或者叫預處理層。

利用可信執行環境 (Trusted Execution Environments, TEEs) 構建隱私沙盒，在沙盒內根據預先確定的排序規則，或者 FIFO 先進先出，進行交易排序。

更好地服務訂單簿 （CLOBs）、永續合約交易所 （Perpetual Exchanges）、暗池 （Dark Pools）協議。

Solana 通常交易打包與 BAM 模式對比

如何理解 BAM 在在 Solana 應用和主網之間，構建了一個排序層？先來個直觀對比。

Solana 正常交易流程，

1）用戶在錢包內確認交易，

2）交易發送到 RPC 節點，

3）RPC 發給當前 Slot 時段內，Solana 主網的 Leader 節點，

4）Leader 收集交易池的交易，排序，打包成區塊廣播，

5）其餘節點投票。

若某應用接入 BAM，交易流程如下，

1）用戶在錢包內確認交易，

2）交易發送到 RPC 節點，

3）交易轉到 BAM 網路，在 TEE 隱私中進行排序。過程中，節點可能通過插件添加額外交易，比如更新預言機價格，然後生成證明，

4）交易數據包提交到 Solana 主網 Leader 節點，

5）Leader 收集交易時，收集到 BAM 數據包，再打包成區塊廣播，

6）其餘節點投票。

所以，其實 BAM 與當前 Solana 主網共識過程並不衝突，而是作爲一個“可選性”。BAM 不直接運行在 Solana 主網上，是以所謂“鏈下”的方式，預先完成交易排序，將交易打包，再提交到 Solana 主網上。

BAM 交易排序模式

BAM 支持三種運行模式，

1）Solana 默認模式；

2）Block-Engine 模式；當前 Jito 的 MEV 解決方案，核心是競價機制。

3）BAM 模式，驗證者嚴格按照 FIFO 先進先出排序。

BAM 模式的核心，有以下幾點，

1）可信執行環境 TEEs：隱私與公平 利用可信執行環境 TEEs，構建隱私環境，對交易進行排序。隱私的另一面叫公平。

2）插件系統 Plugin：復雜排序 通過插件系統，BAM 允許應用構建自定義交易排序邏輯。而這個自定義排序，不是說節點想怎麼排就怎麼排，而是根據預先設定的規則排序。

插件計劃實現復雜的交易排序，同時保持 TEE 環境的安全保證。目前正處於早期開發階段。

如前文所述，

對訂單薄 DEX 來說，理想的排序應該是，隨着價格波動，先執行所有撤單，再執行新掛單，最後執行成交。這是目前 Solana 共識在微觀層面做不到的。

而在預言機報價層面也是一樣，理想情況是，先更新預言機價格，再執行依賴該價格的交易。 但在目前的 400毫秒間隔內，行情可能因劇烈波動，導致成交時仍按原先價格成交。

對借貸協議來說，最好是先補保證金，再來進行清算。 這實際上實現了 ACE 應用控制執行功能。

所以，BAM 到底實現了什麼？

舉例來說，

1）借貸清算保護

對借貸協議來說，檢測到清算風險後，優先執行補充抵押品操作，再進行清算檢查。

2）原子級交易組合

對 DEX，先更新預言機價格，執行依賴該價格的交易。如果是合約 DEX，則還可結算相關衍生品。以上操作，全部在同一個時間窗口內完成。

3）價格波動保護

對 DEX，檢測異常大單，將大單拆分成小塊，分批執行，給市場反應時間，避免連環清算或套利造成死亡螺旋。

4）做市商保護

突發事件發生，毫秒內撤單，預言機更新價格，做市商重新掛單。避免被惡意套利，減小價差。

BAM 本來將在 7 月底推出。

且，隨着 BAM 的部署，Solana 交易體驗將得到顯著改善。BAM 將使 Solana 主網應用的體驗更接近 CEX。

綜上，

BAM 爲 Solana 的交易處理流程帶來了可驗證性、隱私保護和可編程性，讓開發者能夠構建中央限價訂單簿（CLOBs）、永續合約交易所 （Perpetual Exchanges）、暗池（Dark Pools）以及其他需要排序控制、確定性執行和隱私保障的金融基礎設施，從而推動 Solana 生態系統的創新發展。

以上。