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