MEV（二）：Proposer-Builder Separation
Proposer-Builder Separation (PBS) 如何幫助 Ethereum 協議本身及 MEV 生態？
作者：Nic @ imToken Labs
校對：Lambda Guo @ imToken Labs／Chang-Wu Chen @ imToken Labs／Ping Chen
封面來源：Shane Rounce @ Unsplash
先備知識：
對 MEV 有基本的認識，知道 Flashbot 的角色及 Flashbot 對 MEV 的影響
知道 PoS 機制的基本認識以及 The Merge 帶來的改變
了解 mev-boost 架構
Proposer-Builder Separation 指的是將原本 Proposer 所負責，進行交易排序的工作，分拆給另一個角色 Builder 來負責，讓 Proposer 專心驗證區塊並投票以確保 PoS 網路的安全。
而 mev-boost 其實就是一種 PBS：Builder 透過 Relay 去競標收入自己區塊內容的權利，Proposer 透過 Relay 選擇對他最有利的區塊內容。複雜的交易排序由 Builder 來計算，Proposer 只需單純地選擇競標價格最高的區塊內容，如此即便是普通人自己跑的 Proposer 都能享受到 MEV 收益，而不必擔心自己需要參與激烈的 MEV 套利競爭。
而這篇介紹的 PBS 是 由 Ethereum 協議本身去實行 PBS 的規則，而不再像是 mev-boost 一樣是單純 Proposer、Relay 及 Builder 之間沒有強制力的私下協議。
PBS 對 Ethereum 協議本身的好處
在 PBS 中，Proposer 因為不再需要處理交易排序而可以變成 Stateless 的狀態，也就是 Proposer 節點不需保存著 Ethereum 完整的狀態。負責交易排序的 Builder 才需要保存完整的狀態，Proposer 只需要在收到 Builder 區塊內容時驗證 Merkle Proof 就能確認交易會使用到的 Ethereum 狀態，例如 Uniswap 某個 Pool 的餘額及 Alice 本身的代幣餘額，有了狀態 Proposer 就能模擬交易執行來確認交易有效性。
這讓 Proposer 本身的負擔又變得更輕，表示成為 Proposer 門檻又降得更低，就有更多人能成為 Proposer，讓 Ethereum 變得更去中心化。
另外一個優點是 Dank-Sharding 或 Sharding 都會讓區塊容量變得更大，表示 Proposer 負擔會變得更重。在 PBS 中這些負擔是由 Builder 來承擔，因此 Proposer 的中心化程度不會受影響。
In-Protocol PBS a.k.a. enshrined PBS (ePBS)
原本在 mev-boost 中是由被信任的 Relay 來擔任 Proposer 及 Builder 之間的中間人。Relay 負責保管區塊內容，確保 Proposer 會拿到區塊內容但不能輕易偷走 Builder 的區塊內容。但如果 Relay 是惡意的，則 Proposer 和 Builder 都會受害，且他們只能轉向和其他 Relay 合作並期望其他 Relay 不是惡意的。PBS 則是以 Ethereum 協議來取代這個需要被信任的 Relay 角色，如果 Proposer 或 Builder 任一方作惡，都能由 Ethereum 協議本身來施加懲罰（使其付出代價），而不是必須要仰賴對某個角色的信任。
但要移除這個信任的代價不小，首先我們必須要確保
-
Builder 的區塊內容需要被保護，不能直接揭露
-
Proposer 如果偷走 Builder 的區塊內容，他必須要付出代價
-
Builder 如果沒有公佈區塊內容，他必須要付出代價
綜合第 1, 2 點，Proposer 必須要先對 Builder 的區塊內容進行承諾（commit），然後 Builder 才揭露實際的區塊內容。如果 Proposer 違反承諾，改為 propose 其他區塊內容，則他會被懲罰：他的押金被部分沒收（即被 Slash）而且他 propose 的區塊內容無效，也就是收不到該區塊內容的手續費及 MEV。這也是目前 mev-boost 有的懲罰機制。
第 3 點，如果 Builder 沒有公佈區塊內容，Builder 還是要將競標費用支付給 Proposer。這會由 Ethereum 協議來強制執行，也是 mev-boost 做不到的。
以上是 PBS 要做到，用來保護 Proposer 及 Builder 的規則，而實際上該怎麼完成 Proposer 承諾及 Builder 發布區塊內容則有不同方式，後面會介紹。但在那之前，必須要先提到當我們把每個區塊的交易排序權利都交給 Builder 時，即便 Builder 會彼此競爭，都還是會比原本交給 Proposer 排序交易來的中心化許多。這迫使我們必須要加入額外的機制來避免 Builder 審查交易。
Censorship
Censorship 最著名的例子是 2022 年八月美國財政部將 Tornado Cash 列入反洗錢制裁名單，許多 mev-boost 的 Relay 紛紛將 Tornado Cash 的交易加入黑名單。這使得 Tornado Cash 使用者的交易平均需要比普通交易等上數倍的時間才能被收入區塊裡。
註 1：OFAC 甚至將一個只會 Echo 的合約納入制裁名單。註 2：這篇文章分析 OFAC 制裁對 Builder 的影響。註 3：你可以為自己的 Proposer 節點設置一個最低競標價門檻，避免全都採用 mev-boost 的區塊，藉此增加整體網路的抗審查能力。有將近一半的 mev-boost 區塊競標價都沒有到 0.05 ETH 的門檻。
雖然仍有一些 Relay 是不甩 OFAC 的，但在 PBS 中我們沒有 Relay、也不能指望為數不多的 Builder 會願意違背政府的命令。因此我們需要有機制來迫使 Builder 收錄指定的交易。
Censorship 成本
在 mev-boost / PBS 之前（也就是純 EIP-1559 的市場機制），攻擊者想要審查一筆最多願意付 X ETH 的交易（假設交易花費 150k gas），則攻擊者必須要不斷產生並廣播新交易，迫使區塊超過半滿，藉此把 Base Fee 拉高到 BaseFee * 150k > X，如此該交易才不會被收入。假設每個區塊只收入最多 5m gas 的交易（表示攻擊者要自己填滿剩下的 10m gas 才能保持超過半滿），則他每個區塊都要燒掉 ( X / 150k) * 10m = X * 66.67 ETH，等同於每個小時要燒掉約 X * 20000 ETH。
但在 mev-boost / PBS 中，如果 Builder Charlie 想要審查一筆交易，他只需要讓他的競標價高過其他 Builder。假設該筆交易的手續費中扣掉 Base Fee 費用後為 P，也就是 Priority Fee 的費用，也就是一個 Proposer 收入這筆交易實際會獲得的手續費，則 P 就是 Charlie 在每個區塊競標時都要額外付出的成本（相比於 Charlie 不審查該筆交易，而是開心收入該筆交易）。而這和 EIP-1559 市場機制相比其實是一個非常低的成本，表示 mev-boost / PBS 讓 Censorship 變得更容易。
不同 Censorship Resistance 的設計
在 PBS 中，因為我們不能仰賴 Builder 是好人，所以我們只能仰賴 Proposer，透過 Proposer 來 (1) 強迫 Builder 收入疑似被審查的交易，或是 (2) 乾脆自己收入疑似被審查的交易。
注意到 (2) 其實打破了前面對 PBS Censorship 的假設，不只有 Builder 可以決定交易排序，Proposer 也可以自己插入交易，也因此 Censorship 自然就沒有那麼容易（Censorship 的成本會回到和 EIP-1559 市場機制一樣高，因為審查者要拉高 Base Fee 讓被審查的交易沒辦法被收入）。
(1) Inclusion List or crList (censorship resistance list)
Proposer 透過指定一個交易清單 crList，要求 Builder 只要區塊還有空位，就必須收入 crList 中的交易，直到塞不下為止。
沒有交易被審查的情況，crList 會為空。如果一個 Proposer 發現一筆交易的手續費符合規定可以被收入，且過去一段時間的 Builder 的區塊都還有足夠空間可以容納該筆交易但卻沒有收入該筆交易的話，就可以懷疑該筆交易正在被審查。輪到他 propose 時他就可以將該筆交易加入到他的 crList 中，要來競標的 Builder 就必須要收入該交易，除非區塊沒有足夠空間。
註：一筆交易是否正在被審查是主觀的，不一定每個 Proposer 都會看到一樣的交易或觀察到一樣的現象。
如此一來，想要審查交易的 Builder 就必須要將區塊用其他交易塞滿，除了這些填充用的交易會一直消耗 Builder 的成本，Base Fee 也會因為區塊持續塞滿而呈指數型上升，導致 Builder 成本跟著指數型上升，其長期的審查成本會遠超過單純 EIP-1559 市場機制的審查成本。
不過想要審查交易的 Builder 可以透過在網路上發布了一系列交易黑名單，要求 Proposer 不要將裡面的交易加入 crList，否則就會拒絕產出區塊。假設有 Proposer 是好人，他寧願收益減少也不會理會 Builder 的威脅，那就沒問題。但如果假設 Proposer 皆為理性的，則他們會因為經濟考量而配合 Builder。因此如果我們要能在 Proposer 皆為理性的情況下還能做到抗審查，那必須要對 crList 機制做一點調整。
Revised (1): Forward Inclusion List
為了避免 Proposer 和來競標的 Builder 有利益關係而臣服，在 Forward Inclusion List 中是由 slot n-1 的 Proposer 來決定 slot n 區塊的 crList。而因為 slot n-1 的 Proposer 收的是 slot n-1 而不是 slot n 的競標收益，所以就沒有利益衝突的問題。
註：提出 crList 的人不一定要是 Proposer，也可以由其他人來負責提 crList，只要能夠避免有利益衝突即可。
(2) Proposer build partial block
除了透過 crList 指定交易的方式，我們也可以讓 Proposer 來直接插入交易。依插入的交易安排在 Builder 區塊的前或後可以分成 Proposer prefixes 或 Proposer suffixes。
Proposer prefixes 中 Proposer 在 commit 時會先插入他自己安排的交易，然後再告訴 Builder 剩下多少 gas 可以用以及這些交易執行完的狀態，讓 Builder 能夠調整區塊內容。
註：這會需要比較彈性的 commit 方式，稱作 Slot Auction（後面會介紹），讓 Builder 先競標到產塊權利再決定區塊內容。
Proposer suffixes 中 Proposer commit 時會順便 commit 一個他想插入的交易清單並交給 Builder，Builder 發布區塊內容後 Proposer 再按照清單裡的順序，一一安插交易到 Builder 的區塊內容之後，直到區塊空間不夠或沒有剩餘交易。
prefixes 和 suffixes 這兩個方法都會加重 Proposer 的責任，而且 Proposer 因為要負責親自插入交易，所以必須要儲存完整的 Ethereum 狀態來進行交易運算，也就沒辦法變成 Stateless 節點。
註：目前比較有共識的是 Forward Inclusion List 的做法。
以上是關於抗審查機制的設計，接下來將繼續完成對 Proposer 如何 commit 及 Builder 如何發布區塊內容的介紹。
mev-boost 中 Relay 要在區塊最終上鏈之前，確保 Proposer 已經做出承諾、確保 Builder 的區塊內容真的存在。我們要怎麼取代這個角色呢？我們可以用 Validator Committee 來取代（以下簡稱 Committee）。另外 Relay 和 Proposer/Builder 之間的溝通管道也會被 p2p 網路取代。
註：目前 PoS 中每個 Slot 會有 1 個 Proposer 及 64 個 Committee 的 Validator要對該 Slot 的區塊進行投票。
也因此這個機制的安全性和穩定性就會變成奠基於 PoS 之上：Committee 中非惡意成員不能超過一定比例、網路連線沒有出現重大延遲，否則會和 PoS 發生 fork 一樣出現錯誤，導致 Proposer 或 Builder 權益受損。但這還是比原本相信一個中心化角色的安全性來得高。
目前的設計中主要以整個過程多快做完分為 Two Slot PBS 及 Single Slot PBS，也就是將整個過程分為兩個 Slot 來做完還是單一個 Slot 就做完（mev-boost 屬於後者）。
Two Slot PBS
Two Slot PBS 中，會新增一個 Intermediate Block 的區塊類別，用來放得標 Builder 的區塊內容。Proposer 在 Slot n propose 一個正常的 Beacon Block，裡面會包含對得標 Builder 區塊內容的 commit，Builder 接著在 Slot n+1 propose Intermediate Block，裡面包含他的區塊內容。可以將兩者視為同一個大區塊，只是分成兩階段（兩個 Slot）來完成，第一階段像是 Block Header，第二階段才是真正的 Block Body，沒有 Beacon Block 就沒有後面的 Intermediate Block（因為沒有 Beacon Block 就沒有贏得競標的承諾）。
區塊都要經過 Committee 投票，變成 Fork Choice Rule 的一部分
這兩個 Block 都要經過 Committee 投票（Attestation），但 Slot n 的 Beacon Block 只有 1 個 Committee 對其投票，而 Slot n+1 的 Intermediate Block 則由剩下的 N-1 個 Committee 對其投票。
投給 Slot n Beacon Block 的投票會被收入在 Slot n+1 的 Intermediate Block 裡，投給 Slot n+1 Intermediate Block 的投票會被收入在 Slot n+2 的 Beacon Block 裡。
如果 Builder 一直沒有看到 Beacon Block，代表 Beacon Block 可能沒有被即時發布，所以 Builder 不會發布 Intermediate Block。但如果該 Beacon Block 過一段時間後出現，是否有可能會導致 Builder 賠錢（必須要支付競標費給 Proposer）？事實上該 Beacon Block 會因為太晚出現而被其他 Validator 的 Fork Choice Rule 拒絕，所以 Builder 不需要擔心。
Single Slot PBS
Single Slot PBS 可以想像成是把 mev-boost 中心化的 Relay 角色換成是去中心化的 Committee：Committee 負責保管區塊內容，等到 Proposer commit 得標 Builder 的區塊內容後，Committee 再合作還原出 Builder 完整的區塊內容並廣播出去。
Two Slot PBS v.s. Single Slot PBS
複雜程度
-
Single Slot PBS 不影響 Fork Choice Rule，因此其 Fork Choice Rule 也不需要像 Two Slot PBS 被改得更複雜，進而影響 PoS 分析難度及安全性。
-
且 Single Slot PBS 和 mev-boost 架構相似，Proposer 和 Builder 不需要做太大的改動就可以切換。
-
但 Single Slot PBS 需要標準化並實作一套加解密用的密碼學技術（目前 Ethereum 本身協議中沒有使用到加解密技術）。
區塊時間影響
-
Single Slot PBS 在一個 Slot 就能執行完，不像 Two Slot PBS 基本上等於把區塊時間延長，兩個 Slot 的時間才能有一個 「完整」的區塊出現
-
Two Slots PBS 可以選擇把 Slot 時間縮短，但代價是對網路狀況的要求和各個角色的負擔會更高，更容易出錯
對 Committee 依賴程度
-
Single Slot PBS 需要 Committee 大部分的成員都在線才有辦法順利解密，如果太多不在線會直接導致無法產出區塊內容
-
Two Slot PBS 則不會因為 Committee 成員不在線而無法產出區塊內容
加入 crList
如果加入 crList，則 Committee 在對區塊投票時（不管是 Single Slot PBS 還是 Two Slot PBS）的規則就要調整一下：如果 Committee 成員在 crList 發布時限之前有收到 crList，則 Builder 的內容需要符合 crList 的要求，如果不符合要求則 Committee 成員當作區塊內容沒有被發布；如果 crList 沒有及時發布，則 Committee 成員不會檢查區塊內容是否符合 crList 要求。
另外因為 crList 並不是包含在區塊資訊中，而是透過 p2p 網路傳遞，所以有可能 Builder 會沒收到 crList，這時候他可能就會選擇不競標或降低競標價格（風險溢價），避免發布區塊內容後才發現 Committee 都有收到 crList，就他沒有收到，導致區塊內容不符合 crList 要求而賠錢。但要真的發生整個 p2p 網路中 Committee 成員都收到 crList，就 Builder 沒收到的機率也不高。
Block Auction v.s. Slot Auction
除了目前 mev-boost 中 Builder 對區塊內容做競標，稱為 Block Auction，另一種做法是對「產出區塊內容的權利」做競標，稱作 Slot Auction。
Slot Auction 給 Builder 更多彈性，他可以先競標取得產出區塊內容的權利再開始組裝區塊內容，但缺點是 Builder 如果預估錯誤就有可能因為最後產出的區塊內容的 MEV 比競標價還少而賠錢，不像 Block Auction 中 Builder 可以確定就是會賺這麼多錢。
[2023.08 新增] Payload-timeliness Committee (PTC)
PTC 是基於 Two Slot ePBS 的新的 ePBS 設計提案。原本在 Two Slot 中 Builder 的 Intermediate Block 也是一個區塊，也會影響 Fork Choice Rule。但在 PTC 中 Builder 組裝的區塊內容則不會是一個獨立的區塊，而是由一群 Payload-timeliness Committee（從原本的 Committee 中再選出一群人）來決定 Builder 是否有即時發布區塊內容。如果 PTC 判定有即時發布，那下一個 Slot（假設是 Slot n+1）的 Proposer 就會將他的區塊接在有 Builder 區塊內容的 Slot n區塊後面；反之，則會接在不含 Builder 區塊內容的版本中。也就是 Slot n 區塊裡會不會有區塊內容是先由 PTC 決定，然後 Slot n+1 的 Proposer 再參考 PTC 的投票來決定要接在哪個版本（有 Builder 區塊內容或沒有 Builder 區塊內容）後面。
更多細節、優缺點分析與和 Two Slot 版本的比較請參考：https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054
總結與重點
-
PBS 能減輕 Proposer 負擔，讓網路更去中心化，並能順利因應未來 Sharding 帶來的區塊容量大幅提升的挑戰
-
當把交易排序權都交給 Builder，自然必須要擔心 Censorship 的問題
-
有幾個抗審查的設計，包含 Proposer 自己排序部分的交易，但目前比較有共識的是採取 Forward Inclusion List 的做法
-
Two Slot PBS 和 Single Slot PBS 是目前 PBS 架構的兩種設計，各有優缺點
-
Single Slot PBS 較簡單，但也較中心化，仰賴單一個 Committee 成員需在線且誠實
-
Two Slot PBS 較去中心化，和 PoS Fork Choice Rule 整合並仰賴多組 Committee 增加安全性但又不需要 Committee 一定要在線，只是缺點是設計較複雜
下一篇將介紹一些 PBS 的補丁，讓 PBS 機制及 MEV 供應鏈更加去中心化。
參考資料與推薦延伸閱讀
-
Single Slot PBS：https://ethresear.ch/t/single-slot-pbs-using-attesters-as-distributed-availability-oracle/11877
-
Single Slot PBS：https://hackmd.io/@vianq8jgSjC9fiZvnjcAvw/ryKYUjbf3
-
Two Slot PBS：https://ethresear.ch/t/two-slot-proposer-builder-separation/10980
-
Two Slot PBS：https://hackmd.io/rin5jq_ITA2TBuWjAn0OxA
-
Why ePBS：https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710
-
PTC ePBS：https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054
-
Forward Inclusion List：https://notes.ethereum.org/@fradamt/H1ZqdtrBF
-
Inclusion List：https://iyusufali.xyz/writings/inclusion-lists
-
解決 Inclusion List 免費資料空間問題的 Inclusion List 設計：https://ethresear.ch/t/no-free-lunch-a-new-inclusion-list-design/16389
Rollup-Relay
另外有人提出了介於 MEV-boost 與 In-Protocol PBS 之間的 Rollup Relay：不把 PBS 加在 L1 的共識層及 p2p 層上，而是把 PBS 實作成一個 L2（即把需信任的 Relay 角色換成一個 L2），但缺點是 L2 Sequencer 的角色是需要被信任的。因為這個點子還很新所以這邊只做簡短介紹，如果未來討論更熱烈會再展開來介紹：https://hackmd.io/@echno/rollup-relay
Special thanks to Lambda Guo, Chang-Wu Chen and Ping Chen for reviewing and improving this post