MEV（三）：PBS 補丁

• 作者：Nic @ imToken Labs

• 校對：Lambda Guo @ imToken Labs／Chang-Wu Chen @ imToken Labs／Kevin Mai-Hsuan Chia
• 封面來源：Abhinav Anand @ Unsplash
• 先備知識：
  • 對 MEV 有基本的認識，知道 Flashbot 的角色及 Flashbot 對 MEV 的影響
  • 了解 mev-boost 及 In ProtocolPBS 架構
  • MEV（二）：Proposer-Builder Separation

將 Builder 角色去中心化？

PBS 解決了 Proposer 和 Builder 之間的信任問題，但 MEV 供應鏈上還有其他角色之間仍然維持著信任關係：Searcher 需要相信 Builder 不會偷走他的 Bundle。如果 Builder 市場變得中心化，Searcher 在這個關係中就更趨弱勢。另外 Builder 中心化也可能破壞 PBS 的穩定，如果 Builder 是一家獨大（Dominant Builder），則 Proposer 們將被迫配合該 Builder 的各種要求，抗審查機制像是 Forward Inclusion List 就會變成一個裝飾。

什麼情況可能會導致 Dominant Builder？

Private Order Flow

Private Order Flow 指的是使用者將交易直接交給特定的 Builder，而不將交易廣播給公開網路。會出現這種情況可能單純是因為

1. 該 Builder 提供更好的交易體驗或特殊服務給使用者，也可能是
2. 該 Builder 直接向錢包商或基礎服務提供商購買「打包這筆交易的權利」（也就是榨取這筆交易的權利）

其中 1. 的例子像是

• 透過 Flashbot 的交易只有執行成功才會上鏈，交易失敗則不會上鏈，也就不會耗費使用者手續費
• Flashbot Protect 保護使用者的交易，避免被榨取 MEV

• 以前曾出現過的 Taichi Network，將使用者交易直接放進自己礦工產出的區塊。曾經協助白帽駭客打漏洞把錢拿走，避免被 Searcher 搶跑

• 未來 Builder 可以提供交易 Pre-Confirmation，也就是提前給使用者一個交易會被收入的保證（例如在第 X 個區塊一定會被收入）。或是提供免費幫使用者取消交易或訂單的服務（反正交易都掌握在他手上）。

這些都是因為特殊的服務而獲得的 Private Order Flow，這樣的 Private Order Flow 對生態系是正向的，因為他能激發 Builder 們去競爭設計更多吸引使用者的功能。但 2. 的例子卻是不利於整體的，因為透過購買而來的 Order Flow 會讓該 Builder 更有競爭力，也能漸漸淘汰其他 Order Flow 更少的 Builder 及拉高新 Builder 加入的門檻，並形成一個正向循環直到最終只剩一個主宰的 Builder。

https://twitter.com/jon_charb/status/1562916395683299329/photo/1

註：錢包商和基礎設施服務商會是下一個 MEV 供應鏈裡重要的角色，因為他們掌握了 Order Flow（也就是使用者交易）的來源及流向。

以上介紹了 Builder 中心化甚至出現 Dominant Builder 的缺點，接下來將介紹兩個目前討論中將 Builder 去中心化（Decentralized Builder）的方案。

Builder 負責從 Searcher 們那蒐集 Bundle 並組出獲利最高的 Bundle 組合，作為向 Proposer 競標的區塊內容。因此將 Builder 去中心化的第一個挑戰便是 Builder 如何用去中心化的方式組出 Bundle 組合。

方案 1：使用可信硬體取代 Builder

方案 1 使用 TEE（Trusted Execution Environment） 或 TPM（Trusted Platform Module），一個可信硬體來取代 Builder 的任務，這個角色會稱為 Aggregator。Searcher 會將 Bundle 內容加密後交給 Aggregator，Aggregator 會以可被驗證的方式運行固定的程式碼，因此 Searcher 不必擔心 Aggregator 會將 Bundle 內容解密後傳給其他人。Aggregator 在收到多個 Bundle 後會計算出最有利的組合，然後向 Proposer 競標，並在得標後釋出區塊內容。基本上就是把 Builder 組區塊的工作交給一個可信的機器人。

註：這個方案並不是真的將 Builder 去中心化，而是改用一個可信任的硬體來取代原本不該被信任的 Builder 營運商，相信（可被公開驗證的）程式碼不會作惡。

https://www.youtube.com/watch?v=fAgrIdyWIqc

有了一個可信的角色來處理問題就輕鬆很多，唯一需要擔心的是 Proposer 和運營 Aggregator 的人合謀，運營 Aggregator 的人可能像是原本的 Builder（Builder 整合 Aggregator 到自己的營運系統裡） 。當 Proposer 和運營者合謀，就能以 Proposer 簽章誘騙 TPM 釋出區塊內容，然後再偷走裡面的 Bundle，最後發布另一個區塊內容。在 PBS 中，Proposer 這樣的行為是要被懲罰的，但 TPM 沒辦法確保 Proposer 給它的簽名最後會被廣播出去當作證據：TPM 只能確保自己本身的執行是正確且可驗證的，沒辦法確保和外界通訊的可靠性。因此我們會需要額外的手段來確保 Proposer 合謀時會被抓到並懲罰，也就是確保證據（Proposer 的簽名）是可得的，稱為 Proof of Availability (of proposer signature)。

選項一：請負責投票的 Validator 一起確保

負責對 Proposer 區塊投票的 Validator 一起來協助確保 Proposer 簽名的可得性，Aggregator 會驗證這些 Validator 的簽名後才釋出區塊內容。這個選項假設這些 Validator 是多數誠實的，且這會需要 Ethereum 協議的改動（請 Validator 對 Proposer 的簽名作簽名）。

選項二：使用其他 Oracle 服務

使用例如像是 Chainlink 的 Oracle 服務，要求 Proposer 把簽名同時送給 Chainlink，Chainlink 再簽名表示自己有 Proposer 的簽名。Aggregator 會在驗證 Chainlink 的簽名後才釋出區塊內容。這個選項假設 Chainlink 不會一起加入合謀。

選項三：Aggregator 組成一個聯盟

多個 Aggregator 可以組成一個聯盟，只有在一定數量的 Aggregator 都相信 Proposer 沒有和運營者們合謀時才釋出區塊內容。

https://joncharbonneau.substack.com/p/decentralizing-the-builder-role

Flashbot 最新的試驗：在 SGX 中進行 Block Building

Flashbot 開源了他們在進行的 Block Building inside SGX 試驗：在可信硬體 Intel SGX 中執行 Flashbot 用 Geth 所寫的 Block Building 程式。目前遇到的問題是 Ethereum 狀態需要太大的儲存空間、處理的效能與延遲，未來要能開放讓 Searcher 來使用還有許多困難需要克服。

詳細可參考：https://writings.flashbots.net/block-building-inside-sgx

方案 2：Aggregator 聯盟

和方案 1 的選項三一樣，由多個 Aggregator 組成聯盟，但在方案 2 中 Aggregator 不是一個可信硬體，而是和原本的 Builder 一樣是由服務商所運營，因此方案 2 等於是多個 Builder 組成聯盟（以下還是用 Aggregator 稱呼）。這樣的設計一樣仰賴多數的 Aggregator 必須是誠實的，否則就能合謀偷走 Searcher 的 Bundle。

當然我們也不能完全仰賴多數 Aggregator 是誠實的，而是要讓他們在合謀犯罪時是可咎責的。Aggregator 聯盟會使用門檻簽章演算法組成一把共同公鑰，Searcher 會將他的 Bundle 以這把共同公鑰加密（只有超過一定數量門檻的 Aggregator 們才能協力解密 Bundle）後再傳給 Aggregator 們，並附上一些資訊協助 Aggregator 們去組合出區塊內容。因為 Bundle 內容是看不到的，所以 Aggregator 要有辦法排序組合這些加密過的 Bundle 就會需要知道每個 Bundle 所牽涉到的帳戶有哪些，例如一筆 AMM swap 的交易中會牽涉使用者 Alice 及 AMM 合約，有了這些資訊 Aggregator 在組合排序交易時就能避免安排兩個相衝突、使用到同一個帳戶的交易而導致區塊內容不合法。

註：Searcher 實際上會傳送給 Aggregator 們的東西包含：加密過的 Bundle、Bundle 的 Access List（Bundle 裡交易牽涉到的所有帳戶）及一個零知識證明來證明這個 Bundle 真的使用到 Access List 裡提供的帳戶。

Searcher 要附上 ZK Proof 證明他的 Bundle 真的牽涉到 Access List 裡包含的帳戶

當 Aggregator 組合出彼此不衝突且獲利最高的 Bundle 們後，就要執行過一遍這些交易以算出這些交易執行後的狀態，然後去向 Proposer 競標。但這裡有個問題：要能算出交易執行後的狀態就會需要交易的完整內容，也就是需要解密 Searcher 的 Bundle 內容，但解密後 Aggregator 就可以偷走 Searcher 的 Bundle 內容。所以我們必須要求 Proposer 先做出承諾：承諾他會收進這一批 Bundle（例如對這些 Bundle 做成的 Merkle Tree Root 簽章），如果最後 Proposer propose 的區塊和他承諾的 Bundle 內容不一樣，Proposer 就會被懲罰（被 Slash）。

Aggregator 請 Proposer 對 Bundle 簽名，作為會包含這些 Bundle 的承諾

只有在拿到 Proposer 的承諾後，Aggregator 們才會合力解密 Bundle

不過這個懲罰規則會需要 PBS 機制配合修改或使用像是 EigenLayer 這樣的協議（下一段會快速介紹 EigenLayer），因為目前 PBS 設計中，Proposer 不是針對「會收進哪些 Bundle」做出承諾，所以我們沒辦法在 Proposer 的區塊漏了某個 Bundle 時懲罰他。

EigenLayer

EigenLayer 是一個旨在提升 Ethereum Validator 效益和信任成本效率的協議。Ethereum Validator 目前質押了 32 ETH，只單純負責參與 PoS 共識，如果我們能透過另外的協議來讓 Validator 參與到其他各式各樣的機制呢？例如 Validator 可以選擇同時成為一個 Oracle 為 DeFi 協議提供預言機服務，增加收益。如此 Validator 可以選擇透過 EigenLayer 提升他的資本利用率，且整個生態系也不會因為「又一個 Chainlink」的出現而突然又多出了一個新的幣只為了「確保該預言機的安全性」，而是可以直接沿用現有 Validator 及其 ETH 的質押，可說是一石二鳥。

因為要能在 Validator 違反規定時懲罰他、收走他的押金，所以 Validator 會需要透過 EigenLayer 的 Restaking 機制將質押的 ETH/stETH 等代幣鎖進 EigenLayer 合約。Validator 如果有違規的紀錄就會在合約裡被收取罰金，剩下的才會在 Validator 贖回時退還給 Validator。

EigenLayer 是 Validator 的人力市場，Validator 透過 Restaking 加入 EigenLayer 以獲得打工機會

藉由 EigenLayer，Validator 可以自行選擇承接其他工作，獲得原本 Staking 獎勵外的收益。接越多工作的收益就越多，但相對地風險（因違規被罰款）也越高。

透過 EigenLayer，我們就可以彈性地去新增或修改 Proposer 需要遵守的規則，讓 Proposer 對「會收進哪些 Bundle」做出承諾，並在他的區塊漏了某個 Bundle 的時候懲罰他、沒收他的 ETH。

去中心化 Builder 的優勢

不管是方案 1 還是方案 2，去中心化的 Builder 對 Searcher 或是整個生態系來說都是一個改善，但我們不能強迫 Builder 變成去中心化，而是要確保去中心化的 Builder 是有優勢的，如此才能透過市場來驅動 Builder 去中心化，否則如果去中心化 Builder 沒優勢，肯定競爭不過中心化 Builder（因為去中心化的成本），那最後一樣只有中心化 Builder 能存活。

多個 Builder 聯合組成的去中心化 Builder 會比中心化 Builder 有更好的安全保障。以提供交易 Pre-Confirmation（提前給使用者保證一定會收入他的區塊）這個功能為例，Builder 會需要透過簽名來提供保證，讓使用者可以知道如果 Builder 違反承諾則他的簽名會讓他付出代價，例如沒收押金。而去中心化 Builder 因為有更多 Builder 參與且都要簽名，也就表示加總起來的押金更多，給使用者的保證也就更高。這樣的保障也適用於其他 Builder 可以提供的功能、服務。另外多個 Builder 表示會比單一 Builder 有更多 Order Flow 來源，也就更有機會造出價值更高的區塊內容，增加競爭力。

當然還有去中心化本身提供的優勢，例如 Searcher 可以更安心地交出 Bundle、整個系統的抗審查能力的提升。但相對地去中心化一樣有其劣勢，例如建置成本較高、使用者請求的延遲時間會因為 Builder 要彼此溝通來達成共識而比較高，另外提供新功能或服務的效率也會比中心化 Builder 來得低。

MEV Smoothing

MEV Smoothing 想要解決的問題是：MEV 並非每個區塊都會出現或是每個區塊能賺取的 MEV 收益都差不多，事實上 MEV 的出現及收益大小是非常不穩定的。大型的 Staking Pool 會比小型或甚至 Solo 的 Validator 更有機會獲得偶發的超高 MEV 收益，因為他們的 Validator 成為 Proposer 的機率更高，長久下來大型 Staking Pool 收益會高於小型 Pool 或 Solo Validator，導致後者被競爭淘汰造成 Validator 中心化。另外這個不穩定性也會讓攻擊者更有動機去發動 Reorg 來劫走 MEV。

Flashbot 研究員抓取時間長度為四個月的鏈上資訊（約 90 萬個區塊），模擬有 20 萬個 Validator 的情況下每個 Validator 的平均年化，發現 MEV 獲利呈現的是一個長尾分佈（Long-tail Distribution）而非常態分佈。

來源：https://notes.ethereum.org/cA3EzpNvRBStk1JFLzW8qg#Smoothing

第一張圖是 MEV 年化（x 軸）與 Validator 數量（y 軸）的關係，呈現長尾分佈。

來源：https://notes.ethereum.org/cA3EzpNvRBStk1JFLzW8qg#Smoothing

第二張圖是 Validator 百分比（x 軸）與 MEV 年化的第 p 百分位數（y 軸）的關係。當 p=50（x 軸），p-th percentile=1.45（y 軸），表示 50% 的 Validator 年化小於 1.45%。而 Validator MEV 年化的中間值（Mean）是 1.97，整整比中位數（Median） 1.45 高上 36%，且中間值約落在 p=70，表示約有 70% 的 Validator 是賺不到中間值（整體平均）的。

註 1：台積電 2021 年的平均薪資（Mean）是 246 萬，比中位數 206 萬高出近 20%。總裁薪資是中位數的 194 倍。

註 2：2021 年 Flashbot 即曾以當時的 MEV 資料對 Eth 2.0 的 MEV 進行分析及預估：https://hackmd.io/@flashbots/mev-in-eth2#factoring-in-time-amp-REV-distribution。

Committee-driven MEV Smoothing

而 MEV Smoothing 則是提議讓 MEV 收益平均分配給該 Slot 的所有 Validator，而不再是讓 Proposer 一個人獨佔。以這個設計再以上面的資料模擬則可以得到更趨於平均分佈的 MEV 年化：

來源：https://notes.ethereum.org/cA3EzpNvRBStk1JFLzW8qg#Smoothing

註：所有 Validator 會被平均分配到一個 Epoch 裡的每一個 Slot（一個 Epoch 有 32 個 Slot），每個 Slot 的 Validator 會再被平分到 64 個 Committee。

當然 Proposer 不可能願意主動把 MEV 平分給其他人，所以我們必須改變一下 PBS 機制及共識機制，讓 Committee 參與到 PBS 中，給他們話語權，避免 Proposer 和 Builder 聯手做一個象徵性的競標過程，然後私底下把 MEV 交給 Proposer 獨佔。

Validator 投票時要確保 Proposer 選了收益最高的區塊

當 Validator 在投票時，除了看 Proposer propose 的區塊是否合法且即時 propose 之外，現在要多一個規則是：該區塊的 MEV 收益必須是該 Validator 看到的所有競標中收益最高的，如果 Validator 看到有 Builder 競標 X ETH 但 Proposer 最後選擇另一個競標費小於 X 的區塊時，Validator 就不會投給它。只要有足夠多的 Validator 觀察到這個情況，Proposer propose 的區塊就會因為投票數不夠而被捨棄，也就是被 Fork Choice Rule 所淘汰，最後拿不到任何收益（連 propose 的獎勵都沒有）。

Validator 看到 Proposer 選擇最高競標費的區塊所以投給他

Validator 看到 Proposer 不是選擇最高競標費的區塊所以不投給他

當然如果 Committee 中有足夠多的 Validator 是壞人的話，他們是可以故意不投給 Proposer 的區然後塊再搶走他區塊裡的 MEV 的。不過 PoS 目前已經假設 Committee 大多數 Validator 是好人，畢竟如果大多數 Committee 的 Validator 是壞人，他們是能做出比偷走 MEV 嚴重許多的傷害。而且偷了以後一樣得平分給其他 Validator，所以這個攻擊的實際收益並不高。

假設多個競爭的 Builder 並存且網路狀況良好

不過在這個設計中，必須假設有多個彼此競爭的 Builder 存在以及 Builder 的競標資訊都能順利傳播給網路中的其他 Validator。畢竟如果只有一個 Dominant Builder 存在，則透過 Validator 投票來迫使 Proposer 選擇收益最高的區塊也是徒勞無功，因為只有一個 Builder 在競標而已。或如果 Validator 因為網路問題看不到其他 Builder 的競標，那效果也是一樣受限。

不過我們沒辦法確保所有 Validator 都能看到每個 Builder 的競標。有可能因為網路或時間差導致每個 Validator 看到的當前競標狀況不一樣，就如同現在網路中每個節點看到的「等待被收入的交易」也不會完全一樣。那 Builder 是否可以利用這一點來攻擊 Proposer，例如將競標延後送出導致只有部分的 Validator 即時收到（Proposer 沒有收到），藉此誘導他們對 Proposer propose 的區塊投下反對票？沒錯，所以我們會需要設立一個 Builder 競標的死線，只有在死線之前廣播出來的競標才會被 Validator 考慮，確保 Proposer 和每個 Validator 看到的競標情況能夠越一致越好。

在死線前只有 Builder B 和 C 送出競標

Builder A 死線後才送出競標，雖然競標費更高，但一樣不會被 Proposer 和 Validator 接受

MEV Burn

MEV Burn 是近期提出的構想，大意是將 MEV 也變成像 EIP-1559 Fee Market 裡的 Base Fee 一樣給燒掉。Proposer 躺著賺 Builder 的競標費，但會有像前面 MEV Smoothing 提到的大型 Staking Pool 比小型或 Solo Validator 更容易獲得高額的 MEV 收益，如果改成將這筆收益燒掉，那Proposer 就不會因為 MEV 收益而導致大者恆大、中心化的問題（因為 MEV 收益都被燒掉了），所以這其實也是一種簡單版本的 MEV Smoothing — 直接燒掉 MEV 收益，讓 Proposer 都只靠區塊獎勵過活。

MEV Burn 大概的運作機制是將 Builder 的競標機制複製搬到 Proposer 中，每個 Slot 會有多位 Validator 被選出，可以競標成為 Proposer 以獲得區塊獎勵，而競標費用來源就會是 Builder 的競標費用。得標的 Validator 成為 Proposer，propose 出價最高的 Builder 的區塊，從 Builder 那獲得區塊內容的競標費，但同時也要上繳自己成為 Proposer 的競標費，然後協議會將 Proposer 競標費燒掉，並給予 Proposer 區塊獎勵。

被選出的 Validator 也要透過競標才能成為真正的 Proposer

當然 Validator 也可以嘗試競標少一點的價格，藉此從 Builder 競標費與自己競標費的價差賺點錢，但因為每個 Slot 會有多個 Validator 被隨機選出，所以除非你能掌控所有被隨機選出的 Validator，否則每個 Validator 都會按照各自看到的最高的 Builder 的競標價，去出價競標成為 Proposer，而且兩個價差之間預期會非常小，因為如果 Validator 競標失敗就根本成為不了 Proposer，也就賺不到想賺的價差，甚至是區塊獎勵。

除了能達成類似於 MEV Smoothing 的功效，另外的好處是讓 ETH 能捕捉到鏈上活動產生的價值（也就是 MEV），而不只是單純的作為手續費媒介。而且燒掉更多 ETH 也能增加 ETH 作為資產的價值。以上這兩個好處都特別吸引看好 ETH、將 ETH 作為投資標的的人。

不過這個構想還很新，且也有反對的意見，想了解可多可以參考 Ethresearch forum 的文章 及 Flashbot forum 的文章。

另一種更兼容目前 PBS 的競標設計

後來也有另一種 MEV Burn 設計被提出，在這個新的設計中 Proposer 維持原樣：每個 Slot 固定一個 Proposer，Validator 不需競標成為 Proposer。Builder 一樣競標收入自己區塊的權利，但其中競標費會像 EIP-1559 一樣分為 Base fee 及 tip 的部分，Base fee 會被燒掉，而 tip 會給 Proposer。

而其他投票的 Validator 會負責確保 Validator 選的競標費不會太低，避免 Proposer 和 Builder 合謀來避免 MEV 被燒掉，分贓 MEV。Builder 的競標會公佈到 p2p 網路中，負責投票的 Validator 會監看這些競標費並確認最後 Proposer 選擇的競標費有高於投票 Validator 觀察到的最低的競標費。如果低於最低競標費，表示 Proposer 可能和 Builder 合謀，那 Validator 就不會投給該 Proposer。

這個設計會需要

1. 假設網路順暢，否則 Proposer 有可能真的會沒收到競標資訊
2. 假設投票的 Validator 大部分都是誠實的，避免故意不投給誠實的 Proposer
3. 假設有多個 Builder 在競爭，否則如果只有少數的 Builder 在競爭，則 Builder 很容易結盟一起控制競標費

不過以上這三點假設基本上都是目前 PoS 機制與 PBS 機制已經有的，所以這個 MEV Burn 設計不會額外引入新的安全假設。

Protocol Enforced Proposer Commitment (PEPC)

雖然 In-Protocol PBS（以下簡稱 IP-PBS）的設計還在討論中，但可以確定的是這個機制將會有「非常明確」的設計，這裡的明確並非指清晰明瞭，而是相對於一般性、通用性，這個機制明確定義了「該怎麼做」來「解決某個問題」。例如要解決 Censorship 問題，則機制會加入 Inclusion List、Forward Inclusion List、Proposer build partial block 等等；如果想要讓 Builder 更有彈性地去建構區塊，則可以將競標內容從 Block Auction 改成 Slot Auction；然後還有共識機制要搭配看是 Single Slot PBS 或 Two Slot PBS 去更改。

於是 PEPC 的作者提出一些問題及思路：我們真的要將這個機制設計得這麼「明確」嗎？我們確定這些「明確」的機制真的可以有效解決相對應的問題嗎？這些機制是否有額外的副作用，可能在日後才會浮現？回到 PBS 的初衷：讓 Proposer 負擔越輕越好（才能保持 Validator 去中心化），但加入了這些機制後真的有讓 Proposer 負擔變輕嗎？例如 Proposer build partial block 中 Proposer 也要負責建構一部分的區塊，或像是 Inclusion List 設計中要考慮 Proposer 有可能受制於 Builder 的經濟誘因威脅而不能單純地假設 Proposer 會勇敢對抗審查的 Builder。

另外如果 Proposer 和 Builder 結盟，他們便可以繞過競標過程，私下達成協議（例如 X 個 Slot 之前就先談好到時候會由 Builder 得標），等同於繞過 IP-PBS。而這個可能性就有機會造成積極的 Proposer 和被動的 Proposer 之間的收入差異，如果差異顯著，則會讓 Proposer 都加入積極尋求增加收益的隊伍，也就和我們希望 Proposer 負擔越輕越好的目標背道而馳。

因此他提出了 Protocol Enforced Proposer Commitment（PEPC） 的設計：由協議來強制執行 Proposer 是否遵守承諾所對應的獎賞及懲罰，而和 Proposer 締結契約（立下承諾）的對象則不再限定是 Builder，可以是任何人，且契約內容也不再只有 PBS 中「買賣生產區塊內容的權利」的契約，而可以是各式各樣的契約內容，只要契約內容的條件能寫入智能合約中來實行。

Proposer 和第三方立下各式各樣的契約，並由 PEPC 強制執行獎賞和懲罰

In-Protocol EigenLayer

而我們其實已經有一個可以讓 Validator 和任意第三方進入任意合約關係的設計了，也就是 EigenLayer。因此我們只需要將 EigenLayer 整合進 Ethereum 協議中，就可以有一個協議層級的 Validator 人力市場。

註 1：將 EigenLayer 整合進協議中也能順便彌補 EigenLayer 的一個缺點 — Validator 在 EigenLayer 上被懲罰不會反映在共識層上，也就是共識層不會知道這個 Validator 在其他地方作惡被懲罰了，對共識層來說這個 Validator 還是盡責地在履行他的義務。將 EigenLayer 整合進協議後，共識層就可以知道 Validator 在 EigenLayer 上被懲罰並藉此作出反應，例如扣除他在共識層的押金。

註 2：這裡以 EigenLayer 為例，但未來如果有其他 Restaking 機制都可適用

以 PBS 為例

PBS 中「Proposer 販賣生產區塊內容的權利給 Builder」會是 PEPC 中眾多 Proposer 可以立下的契約之一，在這個例子中 Proposer 所立下的承諾（Commitment）會是：「我會 propose Builder B 所生產的區塊內容，這個區塊內容的 hash 值是 X，如果我 propose 了另一個區塊內容（其 hash 值不是 X），則我的 ETH 押金會被沒收」，這個承諾所定的條件及懲罰都會在 EVM 中去檢查並實行。

註：這會需要 EVM 能夠知道 Proposer 在共識層所 propose 的區塊內容，所以會需要新增一個 Opcode 來讓 EVM 能讀取共識層的區塊內容。

如果 Proposer 的對手方違反承諾，例如 Builder 最後沒有公布區塊內容，則 Builder 一樣要付錢給 Proposer。在 IP-PBS 中 Proposer 和 Builder 的契約規則是寫在共識層，所以共識層可以直接在 Builder 違反承諾時沒收他的錢，但在 PEPC 中則需要將 Builder 的承諾「我願意付出 N個 ETH 來換取生產 Proposer P 的區塊內容的權利，我的區塊內容的 hash 值是 X」變成一個可以在 EVM 中實行的規則，可以是一筆交易或是一個簽名，兌現的條件就是 EVM 確定 Proposer P 的區塊內容的 hash 值的確是 X，只要 Proposer 的確 propose 該區塊內容就可以從該 Builder 身上拿走 N個 ETH。

EVM 可以讀取到共識層區塊內容，所以可以判斷 Builder 是否該付錢

如果是 Proposer 違反承諾，則證據（Proposer 做出承諾的簽名及實際 propose 的區塊內容）也都非常清楚明白，可以直接在 EVM 中檢查並懲罰 Proposer。

Proposer 違反承諾，EVM 可以判斷 Proposer 是否該被懲罰

負責投票的 Validator 所扮演的角色

但如果違反承諾（例如偷走 Builder 的 MEV）所賺的錢更多， Proposer 寧願被懲罰也要 propose 另一個區塊呢？在 IP-PBS 中，負責對 Proposer 區塊投票的 Validator（Attester）知道 PBS 的規則，所以如果發現 Proposer 違反承諾，則他們不會投給他的區塊。但在 PEPC 中，共識層不會知道這些（各式各樣的）契約規則，這些契約規則都是執行層（EVM 裡）的規則，所以 PEPC 中即便 Proposer 違反承諾，Validator 仍然會投給他的區塊。

不過投票的 Validator 真的沒辦法知道 Proposer 是否有違反承諾嗎？其實應該是可以的，畢竟我們都已經假設 EigenLayer 被整合進去協議裡了，Proposer 是否違反承諾應該是可以驗證的吧？例如在 p2p 網路裡分享傳遞著 Proposer 的承諾、違規證據等等，然後 Validator 也將 EigenLayer 契約檢查邏輯整合進去，投票時順便檢查 Proposer 是否有違反在 EigenLayer 上的承諾。如果 PEPC 被採用，可預期各種驗證 Proposer 的承諾的工具會慢慢成熟，方便讓 Validator 驗證 Proposer 是否違反承諾。例如執行一筆簡單的 EVM 交易檢查 Proposer 承諾給 Builder 的簽名，及檢查該區塊內容是否真的是該 Builder 所生產的區塊內容，檢查不通過則回傳 False 或 revert。

Validator 檢查收到的 Proposer 承諾及證據來投票

我們可以要求 Proposer 要主動在區塊內附上這樣的檢查，如果沒有主動附上檢查證明自己有遵守承諾，則 Validator 就不會投給他的區塊。更進階一點，我們也可以把負責投票的 Validator 也加進這份契約中：如果 Validator 投給違反承諾的 Proposer 的區塊，則 Validator 也會被沒收押金。

要求 Proposer 要主動附上證明，證明自己有兌現自己的承諾

註：Proposer 要能在區塊內附上檢查表示 Proposer 要能安插交易到區塊內容裡，也就是不能讓 Builder 完全決定區塊內容。這會需要採用例如在前一篇提到的 Proposer prefixes/postfixes，或其他類似的做法，例如特別規劃一個 10 萬 Gas 的額度給 Proposer 放他的交易。

以上是關於 PEPC 的介紹，PEPC 提供一個更通用的 Proposer 承諾框架，避免如 IP-PBS 定死各種 Proposer 與 Builder 之間的遊戲規則而導致未來假設發現規則有漏洞或規則老舊時，難以進行更新或需要硬分叉來更新。

而至於更通用的 Proposer 承諾到底會讓 Proposer 變得更輕鬆還是更繁重則還有待討論及研究。

總結與重點

• 不好的 Private Order Flow 會導致 Builder 中心化，對 MEV 生態系造成負面影響
• 去中心化 Builder 成本較高，效能也會比中心化 Builder 高，但仍然有其優勢。如果能將 Builder 去中心化，Searcher 及使用者都將受惠
• MEV Smoothing 旨在解決 MEV 收益呈現長尾分佈而導致大型 Staking Pool 比小型 Staking Pool 或 Solo Staker 平均能獲得更多收益的問題，作法為將 MEV 收益平均分配給 Proposer 及所有投票的 Validator
• MEV Burn 則像是 MEV Smoothing 簡單粗暴的版本，直接燒掉 MEV 收益就不需擔心大型 Staking Pool 長久下來會佔有更大優勢，且也能同時增加 ETH 的價值捕獲
• PEPC 有別於 IP-PBS 定死 PBS 相關的規則，提出一個通用的 Proposer 承諾框架，讓 Proposer 能選擇有更多彈性的規則去做出承諾

下一篇我們將焦點移到 Proposer/Builder 之外，介紹幾個從應用、使用者角度出發的設計，讓這些角色從被動的一方轉變為主動的一方，並在 MEV 生態系中獲得一席之地

參考資料與推薦延伸閱讀

Private Order Flow:

• https://twitter.com/jon_charb/status/1562916372505665536?s=20&t=ks_CrF9MmC1kWEygy50v1g
• https://collective.flashbots.net/t/order-flow-auctions-and-centralisation-i-a-warning/258
• https://www.youtube.com/watch?v=ilc3EoSMMDg

Decentralizing Builder:

• https://joncharbonneau.substack.com/p/decentralizing-the-builder-role
• https://www.youtube.com/watch?v=fAgrIdyWIqc
• https://ethresear.ch/t/how-much-can-we-constrain-builders-without-bringing-back-heavy-burdens-to-proposers/13808

• Block building inside SGX:https://writings.flashbots.net/block-building-inside-sgx

• https://bittokoin.substack.com/p/block-builder-decentralization-is

MEV Smoothing:

• https://ethresear.ch/t/committee-driven-mev-smoothing/10408
• https://notes.ethereum.org/cA3EzpNvRBStk1JFLzW8qg

MEV Burn:

• https://ethresear.ch/t/burning-mev-through-block-proposer-auctions/14029
• https://collective.flashbots.net/t/to-burn-or-not/647
• https://ethresear.ch/t/mev-burn-a-simple-design/15590

PEPC:

• https://efdn.notion.site/PEPC-FAQ-0787ba2f77e14efba771ff2d903d67e4
• https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879
• https://mirror.xyz/ohotties.eth/lBEXiiU7yK91OuSn8QyJPM9Db8GuyDFzCEUAj60BWyI

Special thanks to Lambda Guo, Chang-Wu Chen and Kevin Mai-Hsuan Chia for reviewing and improving this post