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）以及其他需要排序的金融設施和其他需要解決生態保障的基礎設施。
以上。
