拓展閱讀：Gate Ventures 研究院：深度解析 MEV，照亮黑暗森林（上）
MEV 減緩探索方向過去 Ethereum 生態(tài)內(nèi)部，PBS 的解決方案是外包給 Flashbots 來實現(xiàn)的，F(xiàn)lashbots 專門用于研究以太坊的 MEV 問題，其最新一輪估值已經(jīng)達到了 10 億美元。但是由于 Relayer 毫無經(jīng)濟效益，并且實現(xiàn) Relay 需要很高的技術和經(jīng)濟門檻，Blocknative 放棄這一賽道項目的研發(fā)。為了解決去信任化以及 0 經(jīng)濟激勵的問題，以太坊也在考慮使用 e-PBS 協(xié)議級別改進，來避免基于第三方協(xié)議 mevboost 的 Relayer 的存在。
當前 MEV 似乎是一個無法很好解決的問題，因為本質(zhì)上這是生態(tài)系統(tǒng)復雜度提升以及用戶時間段內(nèi)信息不對稱的必然產(chǎn)物，對于黑暗森林的以太坊來說，特別是在無需許可和抗審查的黑客思想影響下，以太坊無法在協(xié)議層面進行審查和改進來一次性切斷 MEV，這不可能做到也不會出現(xiàn)。以太坊生態(tài)下，更多的是想辦法減輕 MEV 的負外部性，增強其正外部性。許多的項目、社區(qū)成員、開發(fā)者、VC 都在探索一些值得嘗試的方式，也就衍生出了許多潛在的機會。接下來，我們將大致介紹一些減緩負外部性的嘗試，總的來說，所有的嘗試都是三個方向：協(xié)議級別、應用級別、拍賣機制。
SUVAE
SUAVE（Single Unifying Auction for Value Expression）是 Flashbots 提出的，旨在改善 MEV 負外部性。同樣，其不訴諸于解決 MEV，而是引導 MEV 變得去中心化、透明。
SUAVE 鏈的架構，圖源：Flashbots
其通過構建一個新的區(qū)塊鏈 SUAVE，內(nèi)置了一個 MEVM 虛擬機，該虛擬機能夠運行 EVM 智能合約。同時配套的開發(fā)者工具能夠支持開發(fā)基于 EVM 虛擬機的 MEV 智能合約。從而允許當今任何集中式 MEV 基礎設施轉換為分散式區(qū)塊鏈上的智能合約。這大幅降低創(chuàng)建新 MEV 應用程序的門檻，可以最大限度地提高不同機制之間的競爭，并且?guī)砹巳ブ行幕屯该餍浴Ｗ詈螅兄谕ㄟ^使中心化基礎設施（構建器、中繼器、中心化 RFQ 路由等）能夠被編程為去中心化區(qū)塊鏈上的智能合約來分散 MEV 產(chǎn)業(yè)鏈的中心化問題。
Rollup 交易的供應鏈，圖源：dba:
SUAVE 能夠作為去中心化的排序器以及意圖識別機器提交給鏈上的 Proposer，最后使用以太坊作為結算層。執(zhí)行節(jié)點會在鏈下執(zhí)行，采用可信執(zhí)行環(huán)境或者零知識證明技術。用戶能夠使用意圖交易，將交易交給 SUAVE 去解析，并且最大化的透明 MEV，以進行智能合約間的 MEV 競拍，這樣通過透明的市場機制就能有效的減緩負外部性。同時，根據(jù) Paradigm 的應用稅文章，比如針對 MEV bot 行為，征收應用稅，也是比較適合在 SUAVE 上實施的。而 Paradigm 正好也是本項目的顧問和投資人。
OFA
我們以 OFA（Order Flow Auction）為例，來一覽其對拍賣機制的改進。
OFA 拍賣機制，圖源：Frontier Research
訂單發(fā)起人（錢包 / 應用）將訂單發(fā)送給 OFA，OFA 選擇性的披露部分信息，包括訂單價值等，這個是設計空間。
競標者 Bidders 出價，獲得對應的信息并且提出能夠為此訂單流支付的價格，之后 Bidders 就會對這個訂單流進行 MEV。
這部分私人的訂單流只有 Bidders 能夠看到，并且引入了市場化競爭以后，能夠讓 MEV 更透明，以及盡量減少用戶的損失。
目前業(yè)內(nèi)有不少基于 OFA 拍賣機制的項目正在研發(fā)，整體的運行機制和流程都非常相似，不同點在于四個核心組件之間的細節(jié)與實施方式不同。
私人交易池加密
OFA 類似于構建了一個私人交易池，但是這些用戶訂單只能由某個拍賣機制下獲勝的 Bidders 提取 MEV，拍賣的手續(xù)費返還給訂單所有者。實際上這套架構下仍然存在某種拍賣機制下的 MEV 提取。內(nèi)存隱私池是希望解決對 Searcher 的保密問題，因為 Searchers 是 MEV 的主要參與方。因此只需要通過隱私交易池，讓訂單只有中繼者和區(qū)塊構建者才能看到。其中，加密意味著用戶的交易可能需要支付更高的 Gas，這本身應該是可選的，目前有以下幾種值得探索的加密方法。
多方計算 MPC：多個參與方使用 MPC，這將對多個參與方隱藏交易細節(jié)，在共享排序器處也可以應用 MPC 來分散單一排序節(jié)點的中心化權利。
可驗證延遲函數(shù) VDF：該函數(shù)需要一定的時間 T 來進行計算，并且一旦計算完畢，能夠快速驗證其正確性。通過使用 VDF 可以讓交易順序變成串行執(zhí)行，但是卻會讓大量用戶環(huán)境下體驗變得非常糟糕，延遲時間 T 是一個權衡下的值。
閾值加密 TSS：允許多個參與者共同參與加密和解密過程，而不需要任何單個參與者擁有完整的密鑰。閾值加密可以通過加密交易內(nèi)容，防止攻擊者在交易被確認前看到交易細節(jié)，從而有效防止前跑攻擊。相比于 MPC，TSS 更加簡單，更適合與單一的簽名與私鑰生成等環(huán)節(jié)。Shutter Network 使用 TSS，它允許驗證者在不知道交易內(nèi)容的情況下對交易進行排序和打包,從而防止 MEV 攻擊。
零知識證明 ZKP，能夠在不公布具體信息的情況下，驗證該信息的正確性。目前發(fā)展主要受制于硬件發(fā)展的影響，成本高昂，具體商業(yè)化落地需要時間。Automata Network 提出了一個名為"Conveyor"的隱私中繼網(wǎng)絡,使用多方計算(MPC)和零知識證明來保護交易隱私,同時允許驗證者執(zhí)行必要的計算。
私人交易池加密方案對比，圖源：Flashbots
對于私人交易池的加密有多種可選的加密算法，包括 MPC、TSS、VDF、ZKP 等，但是每種加密算法都有其弊端需要開發(fā)者權衡。其中具備探索性的項目有使用 TSS 算法的 Shutter Network 以及使用的 MPC 和 ZKP 來解決 MEV 的 Automate Network 值得關注。
Execution Tickets
Execution Tickets 是 Justin 在哥倫比亞加密經(jīng)濟學研討會上提出的一種解決 MEV 方案，這是對共識層面上的改進，其經(jīng)歷三個步驟：
其提出了一個 Tickets 市場，獲得 Ticket 的人能夠獲得在未來某個時間段提議執(zhí)行區(qū)塊的資格。通過動態(tài)定價機制，能夠實時調(diào)控流通中的 Tickets 數(shù)量和現(xiàn)有供應調(diào)整價格。每個 Ticket 具體針對哪個 slot 也是隨機選擇的。
其將區(qū)塊分為執(zhí)行和提議兩種，區(qū)塊提議者是隨機選擇的，執(zhí)行區(qū)塊需要 Ticket 才有資格。
執(zhí)行區(qū)塊的 Ticket 持有人有權在分配到的時間段內(nèi)提議執(zhí)行區(qū)塊，并獲得相關的執(zhí)行層獎勵（EL Rewards = TX Fees MEV）。執(zhí)行區(qū)塊提議者需要提供抵押，以確保他們在分配的 slot 中生成執(zhí)行區(qū)塊。如果他們出現(xiàn)雙花或離線，抵押將被沒收。
Slot 被分為了執(zhí)行輪和信標輪（共識輪），當一個 Ticket 被銷毀，那么相當于對應的 ETH 被銷毀，增加了 ETH 的通縮壓力，由于執(zhí)行區(qū)塊和共識區(qū)塊是隨機選擇了，因此這極大的增加了兩者串通的可能性，其問題在于：
但是這個機制會衍生出多塊 MEV 的問題，也就是購買多個連續(xù)區(qū)塊的執(zhí)行 Ticket，這樣可能會擴大 MEV 的利潤以抵消購買 Ticket 的成本。因此這個機制需要很好的設計 Ticket 價格的變化函數(shù)。
該機制仍然沒有解決用戶 MEV 三明治攻擊的問題，只是把用戶的損失，補償?shù)搅巳w網(wǎng)絡的通縮上。
e-PBS
實際上，在 Merge 以后，以太坊并沒有實現(xiàn) PBS，也就是說，構建者和區(qū)塊提議者都需要從驗證者中選擇，但是為了網(wǎng)絡的經(jīng)濟效益最大化，使用 MEV-Boost 作為第三方的 PBS 協(xié)議外解決方案，目前已經(jīng)有 90% 的 Relayer 市場份額。
e-PBS（enshrined PBS）是以太坊為了應對 MEV-boost Relay 作為第三方構建的信任化中間件的解決方案，其將 PBS 納入共識級別，而不再依賴于 Flashbosts 這種三方提供協(xié)議外解決方案。該提案代號為 EIP-7732 。該協(xié)議的目標是讓以太坊協(xié)議層能實現(xiàn)信任最小化的 PBS 解決方案，通過以太坊協(xié)議內(nèi)的機制捕獲絕大多數(shù) MEV，并以以太坊協(xié)議利益最大化的方式，將捕獲的 MEV 分配給參與者。該 e-PBS 類似于我們在 PBS 章節(jié)中提到的工作流程，但是其特點在于消除了 Relayer 角色，Builder 向 Proposer 競價被寫成了共識層的代碼。
ePBS 執(zhí)行流程圖，圖源：mikeneuder
上圖是，ePBS 機制下的 Slot N 流程：
區(qū)塊廣播：t= 0 時，選定的 POS 驗證者提議 N 號插槽的共識層（Consensus Layer，CL）區(qū)塊，該區(qū)塊包含 Builder 的拍賣區(qū)塊出價，但是不包含執(zhí)行負債。
證明截止時間：t=t 1 時，委員會會根據(jù)分叉規(guī)則選擇正確的區(qū)塊，并進行證明。
聚合證明和 payload 傳播：t=t 2 時，廣播 Slot N 的聚合證明，便于驗證。同時 bulider 發(fā)布他們的 ExecutionPayload，以構建該塊的完整版本。
PTC 投票廣播：t=t 3 ，PTC 負責監(jiān)督 Builder 的 Payload 是否按照規(guī)則進行，并且判斷其時機是否有效。
t=t 4 ，下一個區(qū)塊的提議者是將 slotN 的區(qū)塊視為空塊還是正確構建的滿塊就至關重要，這需要下一個區(qū)塊的提議者根據(jù) PTC 的投票和證明來判斷。
需要特別注意的是，為了保證 Builder 在一個 Slot 內(nèi)能及時的提交區(qū)塊負載，（在 Ethereum 2.0 上也需要保證驗證者委員會在一定時間內(nèi)投票以及提議區(qū)塊），在協(xié)議級別的 PBS 中，Builder 仍然傾向于較晚發(fā)布 Payload 內(nèi)容，這樣就有更多機會尋找 MEV，因此在協(xié)議中引入了 PTC（Payload-Timeliness Committee）,顧名思義，其是針對 Payload 構建者的監(jiān)督機制， PTC 可以從經(jīng)濟角度促進 bulider 及時發(fā)布 payload，保證以太坊的安全性。如果 Builder 的 Payload 被定義為不及時，那么 Builder 將無法獲得對應執(zhí)行負載的獎勵。
區(qū)塊解析圖示，圖源：mikeneuder
因此在 ePBS 中，一整完整的區(qū)塊需要兩部分共同組裝，一個是空的 CL Block，是在 slot 剛開始時，由 proposer 構建，里面包含了 Execution Payload Header 和 Builder Bid，但是具體的 Payload 內(nèi)容暫時為空。只有在證明聚合以及區(qū)塊傳播階段，也就是 PTC 認可 payload 有效性后，才會主裝到區(qū)塊中，形成一個完整區(qū)塊（Full Block）。
總的來說，EIP-7732 ePBS 能夠解決：
無需信任的中間第三方的透明區(qū)塊拍賣方案。
分離共識層和執(zhí)行層來減少驗證者的計算負荷，從而提高網(wǎng)絡效率和速度。
驗證者能夠立即專注于驗證共識，并將執(zhí)行負載的驗證推遲到以后的時間，引入額外的時間窗口和投票機制，確保了系統(tǒng)的高效運行和公平性，同時允許更多的時間來處理執(zhí)行負載。
但是也提出了一些問題有待討論：
本質(zhì)上這只是使得過去第三方 Relayer 的工作被取代，以此來實現(xiàn)區(qū)塊提議流程中的去中心化和透明，但是本質(zhì)仍然沒有解決用戶的糟糕 MEV 體驗。
這次升級是共識層的更改，是不具備向后兼容性質(zhì)的，如果 ePBS 的機制設計在實踐中被驗證失敗，后續(xù)的補丁較難。
假設在一個插槽中，提議者發(fā)布了區(qū)塊，但構建者由于某種原因延遲發(fā)布執(zhí)行負載。這時，部分驗證者可能會基于提議者的區(qū)塊進行驗證，而另一些驗證者可能會等待構建者的執(zhí)行負載，導致網(wǎng)絡分裂。這樣的分叉會增加網(wǎng)絡的不穩(wěn)定性和維護成本。
如果某個提議者故意在接近證明截止時間發(fā)布區(qū)塊，可能會導致部分驗證者看到區(qū)塊，另一些驗證者未看到區(qū)塊，那么 N 1 個 Slot 的 Proposer 的行為將變得不可預測，極大增大鏈上分叉的可能性。
PEPC
同時 EigenLayer 也提出了一些解決方案，包括 AVS 組件 PEPC（protocol-enforced proposer commitments）來解決 MEV 的問題。這個組件也希望解決第三方中間件 Relayer 的信任問題。主要是希望 Proposer 在提交 CL 塊時，能夠附帶一個 PEPC 簽名，來承諾。Builder 通過驗證 Proposer 的 PEPC 之后再執(zhí)行負載，這在協(xié)議內(nèi)引入了一個信任機制。通過內(nèi)置的信任機制，也能解決 Relayer 作為第三方的潛在信任問題。
參考資料
《The MEVM, SUAVE Centauri, and Beyond》：https://writings.flashbots.net/mevm-suave-centauri-and-beyond
《Blockchains, MEV and the knapsack problem: a primer》：https://arxiv.org/html/2403.19077v1
《MEV ECOSYSTEM EVOLUTION FROM ETHEREUM 1.0 》
《The Future of MEV》 by Blockchain Capital
《FRP-18: Cryptographic Approaches to Complete Mempool Privacy》by Flashbots
《Execution Tickets》:https://ethresear.ch/t/execution-tickets/17944
《Payload-timeliness committee (PTC) – an ePBS design》：https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054
免責聲明：
以上內(nèi)容僅供參考，不應被視為任何建議。在進行投資前，請務必尋求專業(yè)建議。
訂單發(fā)起人（錢包 / 應用）將訂單發(fā)送給 OFA，OFA 選擇性的披露部分信息，包括訂單價值等，這個是設計空間。
競標者 Bidders 出價，獲得對應的信息并且提出能夠為此訂單流支付的價格，之后 Bidders 就會對這個訂單流進行 MEV。
這部分私人的訂單流只有 Bidders 能夠看到，并且引入了市場化競爭以后，能夠讓 MEV 更透明，以及盡量減少用戶的損失。
目前業(yè)內(nèi)有不少基于 OFA 拍賣機制的項目正在研發(fā)，整體的運行機制和流程都非常相似，不同點在于四個核心組件之間的細節(jié)與實施方式不同。
私人交易池加密
OFA 類似于構建了一個私人交易池，但是這些用戶訂單只能由某個拍賣機制下獲勝的 Bidders 提取 MEV，拍賣的手續(xù)費返還給訂單所有者。實際上這套架構下仍然存在某種拍賣機制下的 MEV 提取。內(nèi)存隱私池是希望解決對 Searcher 的保密問題，因為 Searchers 是 MEV 的主要參與方。因此只需要通過隱私交易池，讓訂單只有中繼者和區(qū)塊構建者才能看到。其中，加密意味著用戶的交易可能需要支付更高的 Gas，這本身應該是可選的，目前有以下幾種值得探索的加密方法。
多方計算 MPC：多個參與方使用 MPC，這將對多個參與方隱藏交易細節(jié)，在共享排序器處也可以應用 MPC 來分散單一排序節(jié)點的中心化權利。
可驗證延遲函數(shù) VDF：該函數(shù)需要一定的時間 T 來進行計算，并且一旦計算完畢，能夠快速驗證其正確性。通過使用 VDF 可以讓交易順序變成串行執(zhí)行，但是卻會讓大量用戶環(huán)境下體驗變得非常糟糕，延遲時間 T 是一個權衡下的值。
閾值加密 TSS：允許多個參與者共同參與加密和解密過程，而不需要任何單個參與者擁有完整的密鑰。閾值加密可以通過加密交易內(nèi)容，防止攻擊者在交易被確認前看到交易細節(jié)，從而有效防止前跑攻擊。相比于 MPC，TSS 更加簡單，更適合與單一的簽名與私鑰生成等環(huán)節(jié)。Shutter Network 使用 TSS，它允許驗證者在不知道交易內(nèi)容的情況下對交易進行排序和打包,從而防止 MEV 攻擊。
零知識證明 ZKP，能夠在不公布具體信息的情況下，驗證該信息的正確性。目前發(fā)展主要受制于硬件發(fā)展的影響，成本高昂，具體商業(yè)化落地需要時間。Automata Network 提出了一個名為"Conveyor"的隱私中繼網(wǎng)絡,使用多方計算(MPC)和零知識證明來保護交易隱私,同時允許驗證者執(zhí)行必要的計算。
私人交易池加密方案對比，圖源：Flashbots
對于私人交易池的加密有多種可選的加密算法，包括 MPC、TSS、VDF、ZKP 等，但是每種加密算法都有其弊端需要開發(fā)者權衡。其中具備探索性的項目有使用 TSS 算法的 Shutter Network 以及使用的 MPC 和 ZKP 來解決 MEV 的 Automate Network 值得關注。
Execution Tickets
Execution Tickets 是 Justin 在哥倫比亞加密經(jīng)濟學研討會上提出的一種解決 MEV 方案，這是對共識層面上的改進，其經(jīng)歷三個步驟：
其提出了一個 Tickets 市場，獲得 Ticket 的人能夠獲得在未來某個時間段提議執(zhí)行區(qū)塊的資格。通過動態(tài)定價機制，能夠實時調(diào)控流通中的 Tickets 數(shù)量和現(xiàn)有供應調(diào)整價格。每個 Ticket 具體針對哪個 slot 也是隨機選擇的。
其將區(qū)塊分為執(zhí)行和提議兩種，區(qū)塊提議者是隨機選擇的，執(zhí)行區(qū)塊需要 Ticket 才有資格。
執(zhí)行區(qū)塊的 Ticket 持有人有權在分配到的時間段內(nèi)提議執(zhí)行區(qū)塊，并獲得相關的執(zhí)行層獎勵（EL Rewards = TX Fees MEV）。執(zhí)行區(qū)塊提議者需要提供抵押，以確保他們在分配的 slot 中生成執(zhí)行區(qū)塊。如果他們出現(xiàn)雙花或離線，抵押將被沒收。
Slot 被分為了執(zhí)行輪和信標輪（共識輪），當一個 Ticket 被銷毀，那么相當于對應的 ETH 被銷毀，增加了 ETH 的通縮壓力，由于執(zhí)行區(qū)塊和共識區(qū)塊是隨機選擇了，因此這極大的增加了兩者串通的可能性，其問題在于：
但是這個機制會衍生出多塊 MEV 的問題，也就是購買多個連續(xù)區(qū)塊的執(zhí)行 Ticket，這樣可能會擴大 MEV 的利潤以抵消購買 Ticket 的成本。因此這個機制需要很好的設計 Ticket 價格的變化函數(shù)。
該機制仍然沒有解決用戶 MEV 三明治攻擊的問題，只是把用戶的損失，補償?shù)搅巳w網(wǎng)絡的通縮上。
e-PBS
實際上，在 Merge 以后，以太坊并沒有實現(xiàn) PBS，也就是說，構建者和區(qū)塊提議者都需要從驗證者中選擇，但是為了網(wǎng)絡的經(jīng)濟效益最大化，使用 MEV-Boost 作為第三方的 PBS 協(xié)議外解決方案，目前已經(jīng)有 90% 的 Relayer 市場份額。
e-PBS（enshrined PBS）是以太坊為了應對 MEV-boost Relay 作為第三方構建的信任化中間件的解決方案，其將 PBS 納入共識級別，而不再依賴于 Flashbosts 這種三方提供協(xié)議外解決方案。該提案代號為 EIP-7732 。該協(xié)議的目標是讓以太坊協(xié)議層能實現(xiàn)信任最小化的 PBS 解決方案，通過以太坊協(xié)議內(nèi)的機制捕獲絕大多數(shù) MEV，并以以太坊協(xié)議利益最大化的方式，將捕獲的 MEV 分配給參與者。該 e-PBS 類似于我們在 PBS 章節(jié)中提到的工作流程，但是其特點在于消除了 Relayer 角色，Builder 向 Proposer 競價被寫成了共識層的代碼。
ePBS 執(zhí)行流程圖，圖源：mikeneuder
上圖是，ePBS 機制下的 Slot N 流程：
區(qū)塊廣播：t= 0 時，選定的 POS 驗證者提議 N 號插槽的共識層（Consensus Layer，CL）區(qū)塊，該區(qū)塊包含 Builder 的拍賣區(qū)塊出價，但是不包含執(zhí)行負債。
證明截止時間：t=t 1 時，委員會會根據(jù)分叉規(guī)則選擇正確的區(qū)塊，并進行證明。
聚合證明和 payload 傳播：t=t 2 時，廣播 Slot N 的聚合證明，便于驗證。同時 bulider 發(fā)布他們的 ExecutionPayload，以構建該塊的完整版本。
PTC 投票廣播：t=t 3 ，PTC 負責監(jiān)督 Builder 的 Payload 是否按照規(guī)則進行，并且判斷其時機是否有效。
t=t 4 ，下一個區(qū)塊的提議者是將 slotN 的區(qū)塊視為空塊還是正確構建的滿塊就至關重要，這需要下一個區(qū)塊的提議者根據(jù) PTC 的投票和證明來判斷。
需要特別注意的是，為了保證 Builder 在一個 Slot 內(nèi)能及時的提交區(qū)塊負載，（在 Ethereum 2.0 上也需要保證驗證者委員會在一定時間內(nèi)投票以及提議區(qū)塊），在協(xié)議級別的 PBS 中，Builder 仍然傾向于較晚發(fā)布 Payload 內(nèi)容，這樣就有更多機會尋找 MEV，因此在協(xié)議中引入了 PTC（Payload-Timeliness Committee）,顧名思義，其是針對 Payload 構建者的監(jiān)督機制， PTC 可以從經(jīng)濟角度促進 bulider 及時發(fā)布 payload，保證以太坊的安全性。如果 Builder 的 Payload 被定義為不及時，那么 Builder 將無法獲得對應執(zhí)行負載的獎勵。
區(qū)塊解析圖示，圖源：mikeneuder
因此在 ePBS 中，一整完整的區(qū)塊需要兩部分共同組裝，一個是空的 CL Block，是在 slot 剛開始時，由 proposer 構建，里面包含了 Execution Payload Header 和 Builder Bid，但是具體的 Payload 內(nèi)容暫時為空。只有在證明聚合以及區(qū)塊傳播階段，也就是 PTC 認可 payload 有效性后，才會主裝到區(qū)塊中，形成一個完整區(qū)塊（Full Block）。
總的來說，EIP-7732 ePBS 能夠解決：
無需信任的中間第三方的透明區(qū)塊拍賣方案。
分離共識層和執(zhí)行層來減少驗證者的計算負荷，從而提高網(wǎng)絡效率和速度。
驗證者能夠立即專注于驗證共識，并將執(zhí)行負載的驗證推遲到以后的時間，引入額外的時間窗口和投票機制，確保了系統(tǒng)的高效運行和公平性，同時允許更多的時間來處理執(zhí)行負載。
但是也提出了一些問題有待討論：
本質(zhì)上這只是使得過去第三方 Relayer 的工作被取代，以此來實現(xiàn)區(qū)塊提議流程中的去中心化和透明，但是本質(zhì)仍然沒有解決用戶的糟糕 MEV 體驗。
這次升級是共識層的更改，是不具備向后兼容性質(zhì)的，如果 ePBS 的機制設計在實踐中被驗證失敗，后續(xù)的補丁較難。
假設在一個插槽中，提議者發(fā)布了區(qū)塊，但構建者由于某種原因延遲發(fā)布執(zhí)行負載。這時，部分驗證者可能會基于提議者的區(qū)塊進行驗證，而另一些驗證者可能會等待構建者的執(zhí)行負載，導致網(wǎng)絡分裂。這樣的分叉會增加網(wǎng)絡的不穩(wěn)定性和維護成本。
如果某個提議者故意在接近證明截止時間發(fā)布區(qū)塊，可能會導致部分驗證者看到區(qū)塊，另一些驗證者未看到區(qū)塊，那么 N 1 個 Slot 的 Proposer 的行為將變得不可預測，極大增大鏈上分叉的可能性。
PEPC
同時 EigenLayer 也提出了一些解決方案，包括 AVS 組件 PEPC（protocol-enforced proposer commitments）來解決 MEV 的問題。這個組件也希望解決第三方中間件 Relayer 的信任問題。主要是希望 Proposer 在提交 CL 塊時，能夠附帶一個 PEPC 簽名，來承諾。Builder 通過驗證 Proposer 的 PEPC 之后再執(zhí)行負載，這在協(xié)議內(nèi)引入了一個信任機制。通過內(nèi)置的信任機制，也能解決 Relayer 作為第三方的潛在信任問題。
參考資料
《The MEVM, SUAVE Centauri, and Beyond》：https://writings.flashbots.net/mevm-suave-centauri-and-beyond
《Blockchains, MEV and the knapsack problem: a primer》：https://arxiv.org/html/2403.19077v1
《MEV ECOSYSTEM EVOLUTION FROM ETHEREUM 1.0 》
《The Future of MEV》 by Blockchain Capital
《FRP-18: Cryptographic Approaches to Complete Mempool Privacy》by Flashbots
《Execution Tickets》:https://ethresear.ch/t/execution-tickets/17944
《Payload-timeliness committee (PTC) – an ePBS design》：https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054
免責聲明：
以上內(nèi)容僅供參考，不應被視為任何建議。在進行投資前，請務必尋求專業(yè)建議。
關于 Gate Ventures
Gate Ventures 是 Gate.io 旗下的風險投資部門，專注于對去中心化基礎設施、生態(tài)系統(tǒng)和應用程序的投資，這些技術將在 Web 3.0 時代重塑世界。Gate Ventures 與全球行業(yè)領袖合作，賦能那些擁有創(chuàng)新思維和能力的團隊和初創(chuàng)公司，重新定義社會和金融的交互模式。
官網(wǎng)：https://ventures.gate.io/Twitter：https://x.com/gate_venturesMedium：https://medium.com/gate_ventures
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
