撰文：Tia，Techub News
解決 MEV 問題的過程實際上是在重新制定區塊空間的分配規則。對於MEV，相信大家已經不再陌生，但如果想知道一些以太坊MEV 治理提案究竟在談論什麼，可能依舊需要一些背景資料的補充，因此，本文梳理了自以太坊轉向PoS 後一系列關於治理MEV的提案如PBS、ePBS、PEPC，希望能為大家提供一些背景資訊。
PBS（Proposer Builder Seperatioin）
在以太坊合併以前，解決 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 就是一個很好的例子，因為可能存在外部協定會對現有機制進行變更的情況。當協議本身開始出現滯後性時，這種更改可能就會從外部開始萌發，外部機制的萌發一定是契合目前的市場需求的，但是外部機制是否可信，是否經過嚴密設計以防止潛在問題的出現，甚至外部機制可能會破壞協議，這都尚未可知。
中心化的 Relay
MEV-Boost 被詬病最多的地方在於其中心化的 relay 市場。但這種設定引入了信任問題。 builder 需要相信 relay 不會竊取他們的 MEV。 proposer 也必須相信他們從 relay 收到並簽署的區塊頭是有效的。然而，儘管發揮著至關重要的作用，中繼卻沒有任何經濟激勵，並且運行 relay 也需要一筆不小的開支。去年，還有11 個 relay 為以太坊網路提供支持，但如今，只有 9 個 relay 還在提供服務。
值得注意的是，relay 並不是無需准入的，如Eden 這樣的 relay 就只中繼自己的 builder。還有一些 relay 如 bloXroute 則聲稱會過濾掉搶跑和三明治攻擊相關的交易。從某種程度上來說，relay 也擁有一定的規則制定權。
並且，從 Liveness 的角度來看，由於 relay 的存在，builder 與 proposer 之間無法提供原子級別的確認。假如當 proposer 對區塊頭簽署了 commitment，並且 builder 也提供了 payload 內容，但由於 relay 的失誤（無論是惡意還是非惡意的）而無法及時提交該內容，都會使 builder 和 proposer 承擔損失。
ePBS：將 PBS 封裝進以太坊
不論是出於解決 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 halload 需滿足）
SignedExecutionPayloadHeader 」中選擇一個將其納入（通常會選支付給proposer 價格最高的那個）。並廣播提議的信標區塊“- SignedBeaconBlock
”。 見證者履行見證職責
Aggregators 提交attestation aggregates；同時，builder 廣播execution payload
成員）檢查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 出售的是可程式化的區塊建構權。
小結
以上是目前以太坊共識與MEV的博弈，要從PoW轉向PoS那天說起…的詳細內容。更多資訊請關注PHP中文網其他相關文章！
