多重並發提議者（MCP）利弊分析

作者：Maven11；翻譯：金色財經xiaozou

多重並發提議者（Multiple Concurrent Proposers，以下簡稱MCP）是指讓多個提議者同時處於活躍狀態的機制（需注意勿與多上下文協議Multi Context Protocol或安全多方計算MPC混淆，但它們之間的確存在某些相似性），它是解決審查問題的創新方案。本文將探討爲何讓多個而非單一提議者負責區塊提議成爲改進區塊鏈機制設計的關鍵要素，包括其運作原理與實施意義。

雖然MCP的核心概念相對容易理解，但目前幾乎沒有區塊鏈實際採用該機制。不過從某種程度上看，比特幣的礦池運作模式與多重並發提議者存在相似性——任何運行比特幣全節點的人都能讓交易被打包上鏈。

另一方面，Solana的多重並發構建者機制與完整MCP的實現形態有部分共通點，至少體現了多個不同參與者共同參與區塊構建（但非區塊提議）的理念。而在以太坊上，約95%的區塊通過MEV-Boost構建。雖然同時存在多個活躍的構建者，但每次拍賣只能有一個獲勝者，因此Solana通過多重並發構建者實現的優勢在此並不成立。事實上，目前沒有任何一條鏈能實現多個提議者隨時擁有區塊提議權。

理解MCP最直觀的方式是將其拆解爲兩個層面：多個提議者同時提供區塊，以及這些子區塊的最終合並。

這些提議者羣體很可能採用子委員會形式（類似以太坊現有機制），因爲讓全部驗證者參與並不現實。這也意味着必須確保單個子委員會不被某個質押池壟斷，否則可能引發審查與共謀問題。此外需注意，傳說中的家庭質押者通常技術能力有限——MCP將顯著增加系統復雜度。

以下是MCP值得被採納的核心優勢：

支持多重並發提議者的理由：

--增強抗審查性（在當前瓶頸下尤爲重要）

--在基礎協議層面擴展而非依賴外部方案

--分散MEV（不再由單一提議者或構建者決定交易打包）

實施MCP將直接暴露的問題：

--交易排序（打包與順序）的競爭激化（可能導致PGA現象湧現？）

--無效交易帶來的模擬挑戰

--硬件需求提升

--無效交易的數據可用性問題

--需引入最終性工具

讓我們逐項分析這些特性，首先從優勢開始，再評估潛在問題是否會對技術負擔較重的公鏈構成實施障礙。

1、MCP的優勢

（1）增強抗審查性

當前多數採用確定性終局機制的區塊鏈，其共識過程依賴於單一leader決定區塊內容（存在細微差異）。區塊廣播後，多數驗證者達成共識並將其納入規範鏈。以太坊通過子委員會機制加速出塊（但完整驗證者集達成共識需要更長時間）。在MCP框架下，多個提議者各自構建本地區塊並最終合並，這意味着區塊入口從單一主體（提議者/構建者/中繼器，理想情況下MCP應摒棄這些角色）轉變爲多通道模式。這使得審查難度大幅提升。當存在多個打包主體時，系統的抗審查性將顯著強化。

當前瓶頸（需注意Flashbots等團隊正在改進現狀）的核心在於：單一構建者通過拍賣獲得單一提議者的區塊構建權，而作爲拍賣方的（可信）中繼器進一步加劇了中心化。雖然以太坊核心協議是去中心化的，但現有交易上鏈流程並非如此。Solana同樣面臨Jito中繼/構建者的中心化問題，正試圖通過再質押方案解決（首個真實收益的再質押"AVS"！）。比特幣用戶可通過運行全節點自主解決（成本較低），但這以犧牲終局性爲代價——比特幣採用概率終局性且缺乏MCP實現所需的"最終性工具"，其依賴最長鏈規則。

（2）在基礎協議層面擴展

通常爲解決核心協議問題，大量開發被外包給第三方團隊來修補L1的固有設計缺陷（不僅限於以太坊）。實施MCP意味着直接處理那些原本由鏈外方案解決/引發的問題。這會提高硬件要求（同時增強抗審查性），根據協議用戶對去中心化的需求，可能是值得的權衡。Solana尤其可能採用此方案來應對Jito的中心化問題。此外，由於區塊構建工作被分配給多方，最終將提升整體網路帶寬需求。

（3）分散MEV

MCP最獨特的效果在於：通過讓特定區塊的MEV由多個活躍提議者分攤（而非由單一提議者或構建者壟斷），改變了原有"MEV彩票"模式。驗證者（多數是企業實體）更傾向於獲得穩定收益流，這種機制也能有效防止單方通過交易重排榨取MEV（現狀）。該特性與抗審查目標具有協同效應。

注：如果你曾讀過我們過去的文章，可能會熟悉CAP定理這個術語：這是分布式系統正常運作必須滿足的三項基本特性。

**C：**代表一致性（consistency），即用戶體驗應在所有用戶間保持統一，每次使用系統時都應感覺像是在與單一數據庫交互。

**A：**代表可用性（availability），也就是我們常說的活躍性（liveness），指所有消息都需被系統節點處理並反映在後續區塊/查詢中，所有指令必須得到執行。

**P：**代表分區容錯性（partition tolerance，或抗審查性），意味着系統即使在遭受攻擊或節點網路分裂時，仍需保持一致性與可用性。

MCP是實現CAP定理關鍵要素（特別是抗審查性）的最佳途徑之一——這些要素常被簡單歸爲博弈論問題。請記住：要信任協議本身，而非博弈論。

然而優勢必然伴隨着代價，CAP定理的運作規律表明：偉大成就總伴隨着相應缺陷——幾乎不可能完全兼顧所有特性。因此讓我們審視實施MCP可能引發的問題。

2、MCP需解決的難題

主要問題在於：MCP在某種程度上會引發區塊內的雙重競爭階段。首先是交易打包費，其次是排序費。排序費的處理尤爲棘手，因爲在第一階段，本地生產者僅掌握局部區塊視圖而非全局視圖。這意味着要精確計算特定區塊位置的最優競價是項艱巨任務。

這不僅操作困難，更關鍵的是（在拍賣機制下）這將使我們重回優先Gas拍賣（PGA）時代。雖然抗審查性得到更強保障，但本質上復活了MEV-Boost試圖解決的問題——競爭性區塊的高位Gas費中位數、打包階段的排他性定價等現象。

除排序問題外（包括本地與全局視圖），還存在其他交易相關挑戰。這裏特指區塊的局部-全局視圖傳播過程中，無效交易所引發的問題。考慮到在階段初期（子區塊合並爲多提議者共建區塊前），無法預知狀態變更對其他提議者交易的影響，可能出現提議者相互傳遞無效交易的情況（若這些交易作爲數據可用性內容上鏈，問題會更嚴重）。也可能出現當前MCP集合中的驗證者違反參數限制（如突破最大Gas值）。雖然通過引入仲裁者（或協議內置規則）可在數據可用性披露後，按手續費篩選相同狀態變更的低價交易來解決，但這又讓我們回到已解決的PGA困境。但若完全不採用拍賣等機制讓搜索者/構建者控制區塊位置，則會導致垃圾交易泛濫和延遲博弈惡化——這些都將破壞預確認（preconfs）的可能性。以太坊（Pectra升級後）和Solana還需額外考慮：以太坊的7702提案使交易不再因nonce失效，而Solana本就無交易nonce（帳戶nonce仍存在）。這導致判斷交易有效性的難度陡增——本質上需要模擬所有組合才能確定正確排序，可能給網路帶來巨大帶寬壓力。Solana憑藉較高的硬件門檻可能更易處理，但以太坊無疑需要硬件升級。不過以太坊的潛在解決方案是：在子區塊合並階段，由執行客戶端（而非構建者+中繼器）實際計算排序——這再次印證了硬件升級的必要性。

在數據可用性（DA）方面，如前所述，另一個重要問題是這些無效交易可能被泄露到鏈上（實質上變成免費交易）。這進一步加劇了共識前階段提到的模擬計算負擔——盡管你可以在合並階段過濾無效交易。FOCIL（發送地址而非完整交易）的一些現有實施方案可能被復用（除非完全依賴模擬驗證，但若存在人爲幹預而非協議規則，可能通過使其他交易失效來幹擾模擬過程）。

如前所述，實施MCP很可能需要配備處理同步問題的最終性工具——這也正是前文在共識前排序模擬部分所暗示的。這同時會引發延遲區塊提議的時間博弈問題（MEV-Boost拍賣中已可見此類現象），其影響包括：提議者可能先觀察其他區塊再構建自己的區塊，從而故意發送使他人交易失效的交易（對搜索者尤其有利）。若制定過於嚴格的反時間博弈規則，又會導致性能較差的驗證者被淘汰（意味着更多漏塊情況）。

應對時間博弈的可能方案可借鑑Monad等鏈的改進措施，該鏈採用異步執行（延遲執行）機制。例如可設定規則：單個時段內所有活躍提議者的交易集合完整效果，必須等到全部集合構建完成才能確定。這會顯著限制吞吐量，因爲多個提議者包含相同交易的概率較高。延遲執行還意味着即使交易被"包含"在子區塊中，仍有可能無法進入最終合並區塊，導致出現"已包含卻回滾"的交易（這與開頭提到的雙重包含問題相呼應）。需注意這可能需要特定最終性工具來執行此類操作（包括執行、傳播和最終確認區塊）。

雖然我們主要聚焦以太坊，但值得注意的是Solana正在積極推進MCP。隨着Max Resnick加入Anza以及Anatoly公開表態支持實施，這一趨勢愈發明顯。Anatoly近期發布的文章提及以下關鍵關注點：

--若來自不同驗證者的區塊到達時間不同怎麼辦（這也可能是時間博弈）

--如何合並交易（前文已探討過）

--如何在驗證者間分配區塊容量（最大Gas限制）以實現帶寬最大化

--資源浪費問題（相同交易被多個子區塊包含，前文亦提及此問題）

在Solana上實施MCP的諸多問題通常與以太坊面臨的問題相呼應。不過Solana更注重帶寬和性能優化，這意味着在確保共識穩健的同時，區塊資源管理與區塊合並顯得更爲重要。

我們在文章開頭提到的另一個關鍵點是：MCP不僅能強化協議，還可用於擴展協議。它甚至能通過排序機制將應用專用序列化（ASS）納入協議層。未來可能會出現這種場景：不再是XYZ交易的提議者，而是由應用自身作爲提議者，按照自身需求排序交易集合（這正是Delta項目努力的方向）——或者反過來，應用向提議者提供交易排序規則。值得注意的是，將MEV稅賦轉移至應用方（交易發起者）與MCP結合的方案也正在探索中（由於不再由單一提議者控制打包，實施會更簡單）。

在Max和Anatoly最近的發文中，他們認爲MCP能通過應用專用序列化實現更窄的買賣價差（去中心化納斯達克理念）。當前環境下，如前所述只有單一leader能提議區塊。這意味着當價格波動時，訂單簿中的報價方會試圖撤銷某些報價。在Solana的單一提議者模式下，由於提議者壟斷權力，只能通過Jito拍賣進行。理想情況（如Hyperliquid所示）應優先處理撤單請求，讓做市商維持更窄價差。因此希望通過ASS爲應用實現這一目標——單一leader模式下他們壟斷了拍賣權，而採用MPC後可以消除這種壟斷。不過這種ASS方案很可能僅限於狀態隔離場景。該提案本質是讓應用開發者能定義特定帳戶的優先操作（例如撤單），對指定帳戶優先執行最高優先級交易（不一定是最高小費交易，而是對流動性命脈攸關的撤單操作）。其核心思路是對常規交易設置手續費門檻，同時允許特定優先交易突破限制。

前文討論過的打包費與排序費問題，Solana似乎已有應對方案。打包費歸入交易驗證者，排序費則支付給協議（銷毀）。當從多個子區塊合並時，只需按預設排序費對合並後的交易集合進行排序並執行。

上述機制與Solana的區塊傳播機制Turbine緊密配合。Leaders（MCP）使用數據分片（shreds），將其發送至Turbine樹狀結構中的中繼節點——這些中繼應包含來自所有leader的分片。中繼節點向單一共識leader發送分片確認信息，該leader必須收集足夠多的消息片段後進行廣播並達成共識。

隨着Alpenglow的發布，考慮到單層中繼節點架構及鏈上投票機制的取消（現改爲完全鏈上），具體實現可能有所調整。這些改動有望降低驗證者運營成本，從而增加驗證者數量並吸引技術實力較弱的參與者。這對去中心化固然有益，但可能影響鏈的性能。值得探討的是，在Solana實施MCP後，他們將如何應對驗證者故障問題。

**3、**其他生態中的MCP實踐

Cosmos生態也在推進MCP實施，知名機構Informal Systems剛發布了BFT共識模型下的多提議者規範。他們採用安全廣播協議，通過投票擴展機制要求每個驗證者的子區塊必須獲得其他驗證者確認。Tendermint/CometBFT的區塊構建模塊隨後對這些子區塊集合達成共識，這意味着特定驗證者會產生大量子區塊。

Sei正通過Sei Giga項目研發MCP（力爭成爲首個落地項目），其部分設計靈感來源於Autobahn一文（強烈推薦閱讀）。核心思路是將數據可用性與排序解耦，通過多條並行通道加速數據可用性，最後再排序至全局鏈。這與以太坊的MCP構想略有不同——驗證者並非在固定時段同步出塊，而是持續生產區塊再合並爲全局視圖。

Commonware的Patrick O'Grady也在探索相關方案。

最後，Delta項目設計了一個兼具抗審查公告板功能的底層，同時每個應用運行自己的並發排序器，產生的區塊最終結算至全局狀態層。