信任危機實驗 ePBS的協議內置

TL;DR

• ePBS 的設計核心是圍繞 Builder 安全性而構建的概念，它授予 Builder 對區塊交易的完全控制權。
• ePBS 是將 PBS 直接納入以太坊共識層的提議，被稱為 In-Protocol PBS，旨在應對潛在的中繼故障和消除系統內單點故障。
• ePBS 依舊沿襲原 PBS 的基礎，通過降低單一實體對區塊內容的控制能力，提高網絡的抗審查性和去中心化。
• Payload Timeliness Committee（PTC）作為監督作用，確保新區塊中的交易內容及時性與有效性。

前言

2 月分，Prysm 開發者 Potuz 認為以太坊主網存在信任問題，主張推遲 Electra 分叉至 2025 年，利用Interop event 完善 ePBS 設計。然而，以太坊社區對 ePBS 持有不同意見，部分開發者和研究員擔憂其可能帶來的風險。對於 ePBS，大家的意見各不相同，今天我們將來了解下 ePBS 是什麼？和 PBS 有什麼區別？

之前我們提到過 PBS 的機制是為了確保 Proposer 承諾的安全性和確保 Builder 解釋的安全性，於是將這個權利交給被信任的中繼來承擔。中繼負責保管區塊內容，確保 Proposer 會拿到區塊內容但不能輕易偷走 Builder 的區塊內容。但如果中繼是惡意的，則 Proposer 和 Builder 都會受害，且他們只能轉向和其他 Relay 合作並期望其他中繼不是惡意的。這裡面就存在一個問題，我們必須要找到一個授信第三方從而進行信任委託。因為 PBS 是一種協議外的解決方案。PBS 依賴於社區的共識和自願遵守，需要額外的協調和信任。

PBS中必須有一箇中間人角色作為第三方授信方處理問題：

• Proposer 若想要出售區塊內容的權利必須信任中間人。
• Builder 想要購買構建區塊的權利必須信任中間人。

ePBS 的革命性設計

內置提議者-構建者分離

Enshrined Proposer-Builder Separation（ePBS）內置提議者-構建者分離，是 PBS 衍伸出的又一種變體。ePBS 是一個將 PBS 直接納入以太坊共識層的提議，於是被又稱為 In-Protocol PBS。它的誕生是為了應對潛在的中繼故障和消除系統內單點故障的需求。作為一種新興的共識機制，接下來我們將對ePBS 進行深入解析，旨在闡明其核心原理、優勢以及與傳統 Proposer-Builder Separation（PBS）的區別。

ePBS，即內置提議者-構建者分離，區塊鏈協議中內置的機制。以 Ethereum 協議來取代這個需要被信任的 Relay 角色，如果 Proposer 或 Builder 任一方作惡，都能由 Ethereum 協議本身來施加懲罰（罰沒），而不是必須要仰賴對某個角色的信任。這也是整個協議與之前我們所提到過的 PBS 協議最大的區別和不同。

當然，角色分離在 ePBS 的運用中依舊沿襲原 PBS 的基礎，通過降低單一實體對區塊內容的控制能力從而提高區塊鏈網絡的抗審查性和去中心化程度。

• Proposer：負責區塊提議，包括區塊頭信息
• Builder：構建區塊的具體內容

兩大好處

直接懲處惡行和無需授信第三方

從名字上觀察，就能得知 ePBS 中的 Enshrined 就可以得知因為將協議進行內置的工作，也將會對作惡行為處理做出直接的懲罰，並且信任中心也在該設置下悄然發生轉變。

1. 協議具備識別和處理能力，直接懲處

PBS 中，作惡行為的識別和懲罰需要依賴第三方（validator、relay 等）的介入。而在 ePBS 中，由於其設計在協議內，作惡行為可以直接被協議本身識別和處理。

1. 無需授信第三方，提升去中心化程度

PBS 在一定程度上依賴於外部治理或第三方，存在信任中心化的問題。相比之下，ePBS 通過將規則寫進協議中，從源頭減少了對外部第三方的信任需求，提高了系統的去中心化程度。

*傳統 PBS 與 ePBS 的比較圖

ePBS 設計

執行和驗證之舞

以太坊 POS 中，slot 的時間被分割成 12 秒的間隔。在每個 slot 中，隨機選擇一個驗證者來提議一個區塊。同時，指定一個委員會來驗證區塊有效性。如果一個區塊在給定的 slot 中沒有被提議，4 秒後，負責證明的驗證者將對前一個區塊進行驗證。

source：ethresearch，一個 ePBS slot 將會由 CL（共識層）與 EL（執行層）進行處理。區塊信息在共識層被廣播，接著區塊將被提交給執行層進行驗證。

1. 區塊競價階段：Bulider 將開始競價，發送給 Proposer。
2. proposer 廣播：Proposer 選擇競價並選擇是否運用 Inclusion List 構建自己的區塊內容。接著廣播區塊。
3. 驗證者投票：看到區塊後，會根據其驗證結果投票。
4. 聚合證明（ Aggregate attestation）：聚合證明是由聚合器（Aggregators）創建的，他們將多個驗證者對同一區塊的證明進行聚合。驗證者通過聚合證明進行驗證。
5. payload 廣播：Builder 需要在規定的時間內公開完整的執行有效負載（ution Payload）。
6. PTC 投票：特別委員會，監督和驗證 Builder 的 payload 是否及時和有效。
7. 下一個 slot 的 Proposer 發佈他們的區塊，根據 PTC 的投票結果和聚合證明構建在完整塊或者空塊上。當一個區塊的 PT 票數中及時發佈的百分比更高，那麼它將被視為滿塊。

PTC，監督新區塊中的交易內容及時性與有效性

Payload Timeliness Committee（PTC），“有效負載及時性委員會”。主要任務是確保新區塊中的交易內容能夠及時、準確地被添加進去。這個委員會由驗證者組成（從信標鏈委員會借來的 521 人作為委員會的組成部分），他們的工作是在每個區塊創建週期結束前，檢查 Builder 是否已經完成了區塊的交易填充工作，並且這些交易是按規則正確執行的。

簡單來說，PTC就像是一個監督團隊，監督 Builder 是否按時提交了他們的工作，是否包含了正確交易的區塊。如果 Builder 做得很好，按時提交了符合要求的區塊，PTC 會通過投票來確認這一點。這樣，網絡就能夠知道哪些區塊是完整和有效的，哪些可能存在問題或者不完整。

通過投票機制，PTC 影響區塊是否被視為“完整塊”或“空塊”的狀態。如果 PTC 驗證了負載的及時性和正確性，該區塊可以被認定為“完整塊”狀態；如果沒有負載或負載提交延遲，區塊則可能被標記為“空塊”。接著，根據 PTC 的投票結果，網絡直接對 Proposer 和 Builder 實施獎勵或懲罰，以激勵及時和準確的區塊構建。

• 完整塊（full block）：區塊包含一組有效的 payload，它也可以包含多個交易，並且交易執行狀態會及時更新。
• 空塊（empty block）：區塊幾乎沒有包含任何交易，或者只包含極少數交易。它可以是 CL 塊，但不會更新EL狀態。
• 缺失塊（missing block）：空的slot。在區塊鏈中預期存在但未被創建或未被成功添加到鏈上的區塊。可以通過（block, slot）fork choice 投票，缺失區塊可以被分為滿塊或者是空塊。

ePBS 的抗審查性實現，結合 Inclusion List 的設計

儘管，ePBS 的設計核心是圍繞 Builder 安全性而構建的概念，它授予 Builder 對區塊交易的完全控制權。那麼，在這個基礎上，運用 Inclusion List 將是一個非常完美能夠實現抗審查與去中心化的組合形式。

之前我們的文章中有提到過 CL ，大致講述下流程（詳情可點擊鏈接：undefined。** 向 Builder 提供這份列表，需要優先考慮這些交易。它應涵蓋所有當前活躍的交易，無論是這些交易是否在交易池中。只要區塊還有剩餘空間，列表中的交易應被納入 Builder 的區塊。如果區塊已滿，Builder 應明確標識，並確認他們已經注意到了這份列表。

當 Builder 試圖審查某些交易，由於 EIP-1559 的實施，不斷用交易去填滿的區塊會導致 base fee 迅速上升。若此時 Builder 還堅持通過在區塊中添加虛假交易來審查，不斷增加的費用將使得這種行為成本過高，將變得不再實際。

小結

ePBS 通過協議內置，將提議者和構建者角色分離。通過 PTC 作為證明委員會的一個子集，負責對Builder 發佈的 ution Payload 的有效性與及時性進行投票。其核心優勢在於它將傳統的信任第三方的角色，轉變為由以太坊協議本身來執行監督和懲罰，從而減少了對單一實體的信任需求。不僅提高了系統的抗審查性，還通過 Inclusion List 等機制，增強了對交易的保護，使得審查交易的成本變得高昂而不切實際。

另外聲明下， ePBS 只是提供一個協議層級別的區塊 Proposer 與 Builder 分離的選項，而不是強制性的，他們最大的區別是支付機制和信任模型。當考慮到整個協議的信任問題時，需要付出的代價是需要提前承諾支付費用。與 ePBS 相比，MEV-Boost 可以根據自己排序的 ution Payload 中實現的收益來決定支付給 Beacon Proposer 的金額，具有更多的利潤和空間。或許有一天 ePBS 的機制實現或許無需考慮提前承諾費用的時候，抱有一點小小的幻想和期待！