當前以太坊共識與MEV的博弈要從PoW轉向PoS那天說起

撰文: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 也擁有一定的規則制定權。

數據來自 Rated Network

並且,從 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 的職責則是提議信標區塊。具體流程如下:

  1. 在知道被選爲 Proposer 後,制作並廣播 Inclusion List(IL,即在該 slot 中必須包含的交易)。

  2. builder 們將包含了 execution payload 的區塊哈希以及愿意支付給 proposer 費用的承諾「SignedExecutionPayloadHeader」發送給 proposer(execution payload 需滿足 IL)

  3. proposer 從 builders 發來的「SignedExecutionPayloadHeader」中選擇一個將其納入(通常會選支付給 proposer 價格最高的那個)。並廣播提議的信標區塊「SignedBeaconBlock」。

  4. 見證者履行見證職責

  5. Aggregators 提交 attestation aggregates;同時,builder 廣播 execution payload

  6. 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 的想法才被正式提出。

PEPC(Protocol-Enforced Proposer Commitments)

當然,也有不贊同 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 提供高額回報。

鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播信息之目的,不構成任何投資建議,如有侵權行為,請第一時間聯絡我們修改或刪除,多謝。

相關文章