撰文：Tia，Techub News
解決 MEV 問題的過程實際上是在重新制定區塊空間的分配規則。對於 MEV，相信大家已經不再陌生，但如果想知道一些以太坊 MEV 治理提案究竟在談論什么，可能依舊需要一些背景資料的補充，因此，本文梳理了自以太坊轉向 PoS 後一系列關於治理 MEV 的提案如 PBS、ePBS、PEPC，希望能爲大家提供一些背景信息。
在以太坊合並以前，解決 MEV 的方式是通過使用 Flashbots 开發的 MEV-Geth，MEV-Geth 是一種經過修改的 go-ethereum 客戶端。其核心理念是讓礦工專注於其本職工作——挖礦，而非參與 MEV 爭奪，從而避免可能出現的潛在重組問題。MEV-Geth 的機制很簡單，是一個市場化的解決方案，即礦工在打包區塊時可根據 searcher 提交 bundle 利潤的大小來進行選擇。通過這一巧妙的市場化機制，各方在獲取利益的同時也形成了一定的約束。雖然 searcher 需要將部分利潤分給礦工，但其換來的卻是更加安全的不被礦工偷竊的保障。當圈住了 searcher 這一利潤的主要來源時，礦工也會被動开始使用 MEV-Geth，並進一步被 MEV-Geth 的機制約束。MEV-Geth 會維護一個礦工的白名單，只有在白名單上的礦工才可接收 searcher 的 bundle。通過對礦工進行信譽約束，即將偷竊 searcher 成果的礦工剔除白名單，則可以防止礦工搶奪 searcher 的 MEV 利潤。
但合並後，由於出塊方式變爲從驗證者中隨機選取作爲 proposer 來提議區塊，信譽約束的方式來防止 proposer 搶奪 MEV 就不可行了。
可能的解決方案是讓區塊內容對驗證者不可見。沿着這個思路再進一步完善就是 PBS（Proposer Builder Seperatioin，提議構建分離）。PBS 將作爲 proposer 的驗證者的職責進一步解構爲區塊構建和區塊提議，將復雜的可能參與利益爭奪的構建權外包給 builder，這樣一來，proposer 的工作就變得很簡單，只需對根據 builder 提交區塊的利潤大小進行選擇來提議區塊。
最初，以太坊想要在 merge 的時候將 PBS 嵌入協議內，但由於潛在的復雜性，這一進程就先被擱置了，因此給予了 MEV-Boost 介入到 PBS 的機會。目前，PBS 通過 Flashbots 开發的 MEV-Boost 來實現。除了 builder 和 proposer，其中還有一個很重要的角色——relay。builder 並非將區塊直接發送給 proposer，而是通過第三個角色 relay。
因爲還需要解決一些其他問題，比如如何確保 builder 一定會支付費用給 proposer，且一定會在最後向 proposer 披露區塊內容從而避免 proposer 不會因提交空白區塊而罰沒；比如如何確保 builder 提交的區塊一定會被納入信標鏈等。這些保障 builder 和 proposer 權益的問題，主要通過 relay 來實現。
builder 會將區塊發送給 relay，然後 relay 根據每個區塊能獲得的利潤對區塊進行排序，再將區塊利潤最高的區塊頭發送給 proposer，以此來確保 proposer 對區塊內容不可見。在 proposer 對區塊提議作出承諾（對該區塊頭籤名）後，relay 才會將完整區塊披露給 proposer。builder 支付給 proposer 的費用也需借助 relay 才能確保完成。支付給 proposer 的交易被包含在提交的區塊中，但由於 proposer 無法看到區塊內容，依舊需要由 relay 提前幫忙確認。
In protocol & out protocol
爲了能參與到 MEV-Boost 構建的市場中去，驗證者需要在運行以太坊共識客戶端和執行客戶端的同時，再運行一個第三方的非以太坊的 MEV-Boost 程序。這就是目前所運行着的 PBS 神奇的之處，它讓協議外的第三方參與到了以太坊的共識形成的規則設計中。從所有權的角度來看，這是匪夷所思的。
這也引發了對協議機制「可信度」的思考，可信度是如何被加強的以及又是如何通過其他機制被侵蝕的。MEV-Boost 就是一個很好的例子，因爲可能存在外部協議會對現有機制進行更改的情況。當協議本身开始出現滯後性時，這種更改可能就會從外部开始萌發，外部機制的萌發一定是契合目前的市場需求的，但是外部機制是否可信，是否經過嚴密設計以防止潛在問題的出現，甚至外部機制可能會破壞協議，這都尚未可知。
MEV-Boost 被詬病最多的地方在於其中心化的 relay 市場。但這種設置引入了信任問題。builder 需要相信 relay 不會竊取他們的 MEV。proposer 也必須相信他們從 relay 收到並籤署的區塊頭是有效的。然而，盡管發揮着至關重要的作用，中繼卻沒有任何經濟激勵，並且運行 relay 也需要一筆不小的开支。去年，還有 11 個 relay 爲以太坊網絡提供支持，但如今，只有 9 個 relay 還在提供服務。
值得注意的是，relay 並不是無需准入的，如 Eden 這樣的 relay 就只中繼自己的 builder。還有一些 relay 如 bloXroute 則聲稱會過濾掉搶跑和三明治攻擊相關的交易。從某種程度上來說，relay 也擁有一定的規則制定權。
數據來自 Rated Network
並且，從 Liveness 的角度來看，由於 relay 的存在，builder 與 proposer 之間無法提供原子級別的確認。假如當 proposer 對區塊頭籤署了 commitment，並且 builder 也提供了 payload 內容，但由於 relay 的失誤（無論是惡意還是非惡意的）而無法及時提交該內容，都會使 builder 和 proposer 承擔損失。
不論是出於解決 relay 中心化的問題，還是爲了將協議外的部分移至協議內， 將 PBS 封裝進以太坊的 ePBS 似乎成了一個必選項。目前，ePBS 已不再是討論中的提案了，以太坊 EIP 編輯已經爲其分配編號——EIP-7732。
ePBS 爲 proposer 和 builder 提供了一個無需信任的基礎設施，以供他們來完成區塊構建權的外包。原本在協議外的 builder 的角色被納入了協議內，即驗證者中多拆分出一個 builder 的角色，作爲驗證者的 builder 也需要在以太坊完成質押。由於將共識層原本 proposer 的職責進行了拆分，因此完成 ePBS 需要對共識層進行改動。其中，builder 負責構建 execution payload（該區塊中要被執行的交易的最終列表）。proposer 的職責則是提議信標區塊。具體流程如下：
在知道被選爲 Proposer 後，制作並廣播 Inclusion List（IL，即在該 slot 中必須包含的交易）。
builder 們將包含了 execution payload 的區塊哈希以及愿意支付給 proposer 費用的承諾「SignedExecutionPayloadHeader」發送給 proposer（execution payload 需滿足 IL）
proposer 從 builders 發來的「SignedExecutionPayloadHeader」中選擇一個將其納入（通常會選支付給 proposer 價格最高的那個）。並廣播提議的信標區塊「SignedBeaconBlock」。
見證者履行見證職責
Aggregators 提交 attestation aggregates；同時，builder 廣播 execution payload
PTC（Payload Timeliness Committee，每個 slot 中，都會有 512 個驗證者會被選爲 PTC 成員）檢查 builder 是否及時揭示 execution payload，並對結果進行廣播
ePBS 從提出到最終獲取 EIP 編號中間也經歷了多次討論。最初 PBS 由 Vitalik 在 21 年 6 月提出，4 個月後完善了 Two-slot 這一方案，又過了 3 個月，推出了 Single-slot PBS，直到 23 年 7 月，PTC 的想法才被正式提出。
當然，也有不贊同 ePBS，希望用其他方案來代替的。PEPC 就是如此。ePBS 是將一種確定的規則嵌入協議之中，但在 PEPC 這裏，proposer 出售的是可編程的區塊構建權。
PEPC 是 barnabe 在 2022 年 10 月提出的。barnabe 認爲，如果要將 PBS 機制放到協議內來實現，應當考慮實現一種用於可信信號傳遞的通用機制，而不是實現某一特定可信信號的機制（比如如果讓我構建區塊的話我會返還給你 xx ETH）。
就像 PEPC（Protocol-Enforced Proposer Commitments）的名字一樣，一些確保 builder 以及 proposer 權益的機制是通過 proposer 在協議內提交的 commitment 來完成的，這些 commitments 是能夠在鏈上進行驗證的，主要由操作碼 「BEACONROOT」來實現。這是一個更通用的機制，commitment 可以是將區塊構建權全部外包，也可以是只外包一部分區塊，即 proposer 出售的是可編程的區塊構建權。
以上就是對於 PBS、ePBS、PEPC 的簡單介紹。從協議設計的角度，不僅需要設計一個重新分配 MEV 的市場機制，同時還需要考慮如何才能使驗證者更加去中心化，以及如何才能提高抗審查性。並且，協議的設計中還存在很多取舍。拿已經獲取 EIP 編號的 ePBS 來舉例，雖然 ePBS 的設計解決了中心化 relay 這一難題，但作爲協議外第三方 relay 這一關鍵角色真的只有負面影響么？就從 builder 的支付機制來看，使用 relay 反而更優於 ePBS 機制，因爲 ePBS 是預付費機制，如果 builder 打包了一個超高利潤的區塊，那么在預付費機制下將無法向 proposer 提供高額回報。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。
