信任危機實驗 ePBS的協議內置
TL;DR
ePBS的設計核心是圍繞Builder安全性而構建的概念，它授予Builder對區塊交易的完全控制權。
ePBS是將PBS直接納入Ethereum共識層的提議，被稱為In-ProtocolPBS，旨在應對潛在的中繼故障和消除系統內單點故障。
ePBS依舊沿襲原PBS的基礎，通過降低單一實體對區塊內容的控制能力，提高網絡的抗審查性和去中心化。
PayloadTimelinessCommittee（PTC）作為監督作用，確保新區塊中的交易內容及時性與有效性。前言
2月分，Prysm開發者Potuz認為Ethereum主網存在信任問題，主張推遲Electra分叉至2025年，利用Interopevent完善ePBS設計。然而，Ethereum社區對ePBS持有不同意見，部分開發者和研究員擔憂其可能帶來的風險。對于ePBS，大家的意見各不相同，今天我們將來了解下ePBS是什么？和PBS有什么區別？
之前我們提到過PBS的機制是為了確保Proposer承諾的安全性和確保Builder解釋的安全性，于是將這個權利交給被信任的中繼來承擔。中繼負責保管區塊內容，確保Proposer會拿到區塊內容但不能輕易偷走Builder的區塊內容。但如果中繼是惡意的，則Proposer和Builder都會受害，且他們只能轉向和其他Relay合作并期望其他中繼不是惡意的。這里面就存在一個問題，我們必須要找到一個授信第三方從而進行信任委托。因為PBS是一種協議外的解決方案。PBS依賴于社區的共識和自愿遵守，需要額外的協調和信任。
PBS中必須有一個中間人角色作為第三方授信方處理問題：
Proposer若想要出售區塊內容的權利必須信任中間人。
Builder想要購買構建區塊的權利必須信任中間人。ePBS的革命性設計內置提議者-構建者分離
EnshrinedProposer-BuilderSeparation（ePBS）內置提議者-構建者分離，是PBS衍伸出的又一種變體。ePBS是一個將PBS直接納入Ethereum共識層的提議，于是被又稱為In-ProtocolPBS。它的誕生是為了應對潛在的中繼故障和消除系統內單點故障的需求。作為一種新興的共識機制，接下來我們將對ePBS進行深入解析，旨在闡明其核心原理、優勢以及與傳統Proposer-BuilderSeparation（PBS）的區別。
ePBS，即內置提議者-構建者分離，Blockchain協議中內置的機制。以Ethereum協議來取代這個需要被信任的Relay角色，如果Proposer或Builder任一方作惡，都能由Ethereum協議本身來施加懲罰（罰沒），而不是必須要仰賴對某個角色的信任。這也是整個協議與之前我們所提到過的PBS協議最大的區別和不同。
當然，角色分離在ePBS的運用中依舊沿襲原PBS的基礎，通過降低單一實體對區塊內容的控制能力從而提高Blockchain網絡的抗審查性和去中心化程度。
Proposer：負責區塊提議，包括區塊頭信息
Builder：構建區塊的具體內容兩大好處直接懲處惡行和無需授信第三方
從名字上觀察，就能得知ePBS中的Enshrined就可以得知因為將協議進行內置的工作，也將會對作惡行為處理做出直接的懲罰，并且信任中心也在該設置下悄然發生轉變。
協議具備識別和處理能力，直接懲處
PBS中，作惡行為的識別和懲罰需要依賴第三方（validator、relay等）的介入。而在ePBS中，由于其設計在協議內，作惡行為可以直接被協議本身識別和處理。
無需授信第三方，提升去中心化程度
PBS在一定程度上依賴于外部治理或第三方，存在信任中心化的問題。相比之下，ePBS通過將規則寫進協議中，從源頭減少了對外部第三方的信任需求，提高了系統的去中心化程度。
*傳統PBS與ePBS的比較圖
區塊競價階段：Bulider將開始競價，發送給Proposer。
proposer廣播：Proposer選擇競價并選擇是否運用InclusionList構建自己的區塊內容。接著廣播區塊。
驗證者投票：看到區塊后，會根據其驗證結果投票。
聚合證明（ Aggregateattestation）：聚合證明是由聚合器（Aggregators）創建的，他們將多個驗證者對同一區塊的證明進行聚合。驗證者通過聚合證明進行驗證。
payload廣播：Builder需要在規定的時間內公開完整的執行有效負載（ExecutionPayload）。
PTC投票：特別委員會，監督和驗證Builder的payload是否及時和有效。
下一個slot的Proposer發布他們的區塊，根據PTC的投票結果和聚合證明構建在完整塊或者空塊上。當一個區塊的PT票數中及時發布的百分比更高，那么它將被視為滿塊。PTC，監督新區塊中的交易內容及時性與有效性
PayloadTimelinessCommittee（PTC），“有效負載及時性委員會”。主要任務是確保新區塊中的交易內容能夠及時、準確地被添加進去。這個委員會由驗證者組成（從信標鏈委員會借來的521人作為委員會的組成部分），他們的工作是在每個區塊創建周期結束前，檢查Builder是否已經完成了區塊的交易填充工作，并且這些交易是按規則正確執行的。
簡單來說，PTC就像是一個監督團隊，監督Builder是否按時提交了他們的工作，是否包含了正確交易的區塊。如果Builder做得很好，按時提交了符合要求的區塊，PTC會通過投票來確認這一點。這樣，網絡就能夠知道哪些區塊是完整和有效的，哪些可能存在問題或者不完整。
通過投票機制，PTC影響區塊是否被視為“完整塊”或“空塊”的狀態。如果PTC驗證了負載的及時性和正確性，該區塊可以被認定為“完整塊”狀態；如果沒有負載或負載提交延遲，區塊則可能被標記為“空塊”。接著，根據PTC的投票結果，網絡直接對Proposer和Builder實施獎勵或懲罰，以激勵及時和準確的區塊構建。
完整塊（fullblock）：區塊包含一組有效的payload，它也可以包含多個交易，并且交易執行狀態會及時更新。
空塊（emptyblock）：區塊幾乎沒有包含任何交易，或者只包含極少數交易。它可以是CL塊，但不會更新EL狀態。
缺失塊（missingblock）：空的slot。在Blockchain中預期存在但未被創建或未被成功添加到鏈上的區塊。可以通過（block,slot）forkchoice投票，缺失區塊可以被分為滿塊或者是空塊。ePBS的抗審查性實現，結合InclusionList的設計
盡管，ePBS的設計核心是圍繞Builder安全性而構建的概念，它授予Builder對區塊交易的完全控制權。那么，在這個基礎上，運用InclusionList將是一個非常完美能夠實現抗審查與去中心化的組合形式。
之前我們的文章中有提到過CL，大致講述下流程（詳情可點擊鏈接：undefined。https://mp.weixin.qq.com/s/EBzr0ttBLosYnRBNVKF6rg）Proposer向Builder提供這份列表，需要優先考慮這些交易。它應涵蓋所有當前活躍的交易，無論是這些交易是否在交易池中。只要區塊還有剩余空間，列表中的交易應被納入Builder的區塊。如果區塊已滿，Builder應明確標識，并確認他們已經注意到了這份列表。
當Builder試圖審查某些交易，由于EIP-1559的實施，不斷用交易去填滿的區塊會導致basefee迅速上升。若此時Builder還堅持通過在區塊中添加虛假交易來審查，不斷增加的費用將使得這種行為成本過高，將變得不再實際。小結
ePBS通過協議內置，將提議者和構建者角色分離。通過PTC作為證明委員會的一個子集，負責對Builder發布的ExecutionPayload的有效性與及時性進行投票。其核心優勢在于它將傳統的信任第三方的角色，轉變為由Ethereum協議本身來執行監督和懲罰，從而減少了對單一實體的信任需求。不僅提高了系統的抗審查性，還通過InclusionList等機制，增強了對交易的保護，使得審查交易的成本變得高昂而不切實際。
另外聲明下，ePBS只是提供一個協議層級別的區塊Proposer與Builder分離的選項，而不是強制性的，他們最大的區別是支付機制和信任模型。當考慮到整個協議的信任問題時，需要付出的代價是需要提前承諾支付費用。與ePBS相比，MEV-Boost可以根據自己排序的ExecutionPayload中實現的收益來決定支付給BeaconProposer的金額，具有更多的利潤和空間。或許有一天ePBS的機制實現或許無需考慮提前承諾費用的時候，抱有一點小小的幻想和期待！