Proposer Commitment Protocol Part2

Proposer Commitment Protocol（出塊者承諾協議）要如何確保承諾不被履行時，能找到該負責的角色並懲罰它？

Photo by Timelab on Unsplash

Part1:

Proposer Commitment Protocol Part1

本文無使用 AI 進行或協助寫作。

第一篇文章介紹了什麼是出塊者承諾協議、不同的承諾種類以及目前市面上有哪些協議。這一篇將深入到技術層面，介紹出塊者承諾協議需要哪些元件、遇到的挑戰，還有現有的解法與實作。

Recap: 出塊者承諾協議

目前的 MEV 供應鏈中皆是以整個區塊為單位去販售：由產塊者決定好它的區塊裡包含哪些交易以及交易的順序之後再向出塊者競標。過去社群已有設計提出要讓出塊者能將其區塊內容進行更豐富、更細緻的商品化販售，不過直到最近才因「交易預先確認」這個需求而有契機落地並逐步實現成更通用、更完整的設計。除了較知名的「交易預先確認」例子外，還有像是進階交易或避險用的「區塊期貨市場」，以及能優化交易競標效率的「State Lock」等等。

如何建立一個出塊者承諾的規範

一個出塊者承諾協議最基本需要

1. 一個「註冊表（Registry）」來登記有哪些出塊者（也就是驗證者）和相關角色加入這個協議，以及
2. 訂立「押金與懲罰判斷標準」讓買賣雙方清楚知道其獲得的保障及相對應的風險

1. 註冊表

出塊者承諾協議的相關參與者包含出塊者、產塊者等等，要到註冊表合約來簽名註冊，讓大家知道有誰可以提供承諾，以及什麼時候會輪到這些註冊的出塊者出塊。

出塊者和產塊者要到註冊表來註冊，否則買方（使用者）不知道有誰可以提供承諾服務給他

如果註冊的出塊者太少，那使用者的交易或承諾就會需要等比較久才能被收入或履行，這對於沒有時效性的交易例如一般的轉帳不會有什麼差別，但對於有時效性的交易例如 Swap 或清算交易等等就會有影響。

買方要把「承諾可被兌現的最快時間」這個因素考量進去

像是 MEV-Commit 這個出塊者承諾協議就將承諾區分為 Credible 及 General 兩種：Credible 是由已註冊的「出塊者」提供承諾，而 General 只是由已註冊的「產塊者們」提供。General 承諾不會是最可靠的保障，因為它們只是產塊者，不是有 100% 區塊內容決定權的出塊者。

MEV-Commit 的承諾分成 Credible 與 General 兩種

2. 押金與懲罰判斷標準

承諾的提供者，包含出塊者、產塊者等等，需要將押金鎖進合約，當使用者提供承諾未被履行的證據時，合約將判斷誰該負起責任並燒毀其押金，或是拿押金來賠付給受害者。不過有些承諾未履行的情況未必是承諾提供者作惡，而是單純出塊者機器當機（導致沒有出塊）或是網路出現問題（導致太慢出塊而被其他驗證者拒絕），這些情況會屬於 Liveness Failure，罰則會比較低，畢竟不是惡意的；相對地，如果是有正常出塊但承諾卻還是被違反了，那就屬於 Safety Failure，罰則就會高上許多。

註：L2 排序器也可以是承諾的提供者，它一樣也要鎖押金進合約，才能提供承諾給它的 L2 使用者們。

Liveness Failure 和 Safety Failure 都有可能發生，個字也有相對應的罰則

Liveness Failure 通常比較好判斷，因為沒出塊就是沒出塊；而 Safety Failure 就會按照不同承諾種類有不同的判斷標準，例如「交易預先確認」的承諾就會需要檢查使用者指定的條件，例如「區塊的第一筆」、「區塊最後的十筆之一」，或是「排在哪一筆交易之前/後」等等不同條件。或例如「區塊期貨」的承諾可能會檢查「區塊第 100~500 萬的 Gas 消耗是不是由買家所使用」。在承諾被違反時，使用者都要提供具體證據來證明，而協議也要為這些條件設計好清楚明確的程式碼來進行檢查，否則就有可能會導致有人被冤望而喪失押金，或是有人違反承諾卻還能逃過懲罰。

不同承諾種類如何判斷承諾是否履行

承諾種類 1：「交易預先確認」

「交易預先確認」的承諾又可以分為兩種：交易「收入」的確認或是交易「執行結果」的確認。「交易收入確認」比較簡單，只要交易有在指定區塊、指定的位置被收入即可，不管交易執行結果，適合不會被時間因素或交易順序影響結果的交易，例如一般的轉帳；「交易執行結果確認」則要求交易執行的結果必須符合指定條件，例如「交易不能失敗」、「必須 emit 特定 event」、「某個合約的某個變數必須是某個值」等等。通常「交易執行結果確認」的承諾困難許多，收費也因此比較貴。

以較簡單的「交易收入確認」承諾為例：假設使用者 Alice 希望她的交易 X 能在第 10000 個 Slot 之前被收入，而 Slot 9998 的出塊者或產塊者模擬完交易後決定將 Alice 的交易收入在第 123 筆的位置，因此將交易順序的資訊包含在其承諾中：「在我產出的 Slot 9998 的區塊中，我會收入交易 X ，且會安插在第 123 筆的位置」。在這個簡單的承諾中，有哪些可能出意外的地方？承諾是否履行的判斷標準該怎麼設計來應對不同情境？

出塊者承諾會將 Alice 的交易收入在他的 Slot 9998 的區塊裡的第 123 個位置

在交易收入確認中，使用者只要求在什麼時間點（或之前）被收入，通常不會指定交易要放在第幾筆，因為這種交易不管放在哪個位置都會執行成功，例如一般轉帳。而出塊者或產塊者的承諾中可能會額外包含「交易會放在區塊的哪一個位置」，畢竟它已經模擬完交易，交易順序已經確定。當然出塊者或產塊者也可以不將交易位置的資訊包含在承諾中，反正只要交易有收入在該區塊即可。不過以下介紹會假設承諾中有包含這個資訊，增加一點挑戰性。另外我們會假設是由出塊者來給出承諾。

如果承諾沒有被履行，那首先要先證明「有承諾被打破了」。要證明有承諾被打破，要先檢查最基本的：

• 驗證出塊者對承諾的簽名：證明承諾真的存在
• 驗證出塊者有註冊：證明出塊者真的有加入該出塊者承諾協議
• 驗證該出塊者是 Slot 9998 的出塊者：證明出塊者真的是合法的出塊者

先證明承諾的有效性：(1) 出塊者的簽名、(2) 出塊者有註冊，以及 (3) 出塊的合法性

接著再按不同情況進行驗證：

情況 1. 出塊者當機或網路出問題導致最終沒有出塊或出的塊被遺棄 也就是 Liveness Failure。這時候要證明 Slot 9998 是一個 Missed Slot，也就是沒有出塊的狀態。這需要透過 EIP-4788 在智能合約中讀取共識層的資訊，並提供 Merkle Proof 來證明共識層的 Slot 9998 真的是 Missed Slot 的狀態。當 Missed Slot 證明成功了，該出塊者就會直接被以 Liveness Failure 罰則懲罰。

情況 2. 有正常出塊，但交易在 Slot 9998 之前就被收入

其實如果 Alice 有指定一定要在 Slot 9998 被收入，那交易在 Slot 9998 之前被收入就可能會被視為違反承諾。不過通常使用者都不會介意交易提早被收入（假設交易都執行成功且符合指定條件），且很難避免交易因為公開洩露而導致被其他出塊者或產塊者提早收入，所以協議基本上不會將「交易提早被收入」視為違反承諾。

但因為交易提早被收入代表出塊者沒辦法在 Slot 9998 再次收入該交易，所以 Alice 有可能可以藉此陷害出塊者，畢竟交易 X 就是沒有被收入在 Slot 9998 中。因此如果要能區分到底是「出塊者違反承諾沒收入」還是「使用者想要陷害出塊者」，我們需要使用者去證明「使用者的交易在 Slot 9998 當下是可以被收入的」：如果證明為真，那就是出塊者違反承諾 — 沒有收入該交易；如果無法提出證明，表示交易不可被收入（例如使用者的 Nonce 已經改變或他的餘額不足），那就代表出塊者其實是不得已而不收入該交易。

情況 3. 有正常出塊且該交易在 Slot 9998 可以被收入，但交易沒有被收入，

也就是 Safety Failure。這時候使用者要提供什麼證據呢？

使用者提供的零知識證明除了要包含「交易在 Slot 9998 可以被收入」之外，又分為兩種情況：

1. 第一種可能是區塊交易總數其實少於 123 筆（例如只有 87 筆），所以無法直接證明「X 不是第 123 筆的交易」，這時候要證明「出塊者承諾的交易順位大於 Slot 9998 區塊的交易總數」
2. 第二種是交易總數大於 123 筆，那這時候就直接證明「X 不是第 123 筆的交易」即可

使用者提出有效的證明，驗證通過就直接懲罰出塊者

以上是以「交易收入確認」承諾為例，展示其實光要證明在這種簡單的承諾中「有錯發生」就已經相當複雜、有許多例外需要考慮。而除了證明「有錯發生」以外，還要再接著「指出到底是誰的錯」，這是以太坊複雜的出塊流程所導致。

Remember me for faster sign in

如果以太坊單純只有出塊者負責產塊並出塊，那就簡單許多 —就是出塊者一個人的鍋。但因為以太坊出塊流程背後其實運行著 PBS 機制，讓咎責變得更為複雜 — 區塊內容的產出牽涉到產塊者、Relay 以及出塊者三方。後面會介紹如何咎責。

承諾種類 2：Top-of-block or Bottom-of-block

Top-of-block 或 Bottom-of-block 和「交易收入確認」其實差不多，只是在 Top-of-block 或 Bottom-of-block 中使用者「指定了交易該被收入的位置」。因此它們除了最基本的的「出塊者及承諾的有效性」的驗證，也是要處理前述的幾種會出錯情況，剩下的差別在：相比於證明「交易 X 是否在第 123 筆的位置」，Top-of-block 或 Bottom-of-block 要檢查的可能會是「交易是否是收入在前十筆或最後五十筆之一」等等複雜一點的條件。

註：當然也可能是簡單的「交易是否是收入在第一筆或是最後一筆」檢查，就看 Top-of-block 或 Bottom-of-block 販售者提供的選項。

承諾種類 3：State Lock

State Lock 的承諾例如「在 Alice 的交易之前，Uniswap V3 ETH-USDT 池子的狀態都沒有改變」或「在執行 Alice 的交易之前，Uniswap V3 ETH-USDT 池子的狀態是如何如何」等等，因此使用者要證明 State Lock 承諾被違反時，會需要證明「某合約變數在區塊初始到交易 X 執行之前的值都是 Y」或是「某合約變數在交易 X 執行之前的值是 Y」，但因為現在的以太坊已經為了效能而不再記錄每筆交易執行後的狀態根（State Root），因此要證明某合約變數在任意時間點的值並不容易。

EIP-98 將「執行後的狀態樹根」從交易收據裡移除，否則 State Lock 承諾便可利用收據裡的狀態樹根來證明那當下的任何合約變數。

Alice 指定池子的價格，這個承諾需要鎖定 Alice 的交易執行前該池子的狀態

EIP-98 前的交易收據裡會有執行後的狀態樹根，因此可以用來證明交易執行後的任意狀態

EIP-98 後交易收據裡就沒有狀態樹根，必須要透過其他方法來證明

一個方式是透過挑戰機制讓雙方攻防，直到範圍縮小到一個特定時間點再去執行，得到執行後的狀態樹根。另一個方式是直接以零知識證明的方式證明「某合約變數在時間點 T 的值是 Y」。目前 zkVM 協議像是 Succinct SP1 或 Boundless Steel 其實都可以證明任意的交易執行，或甚至是任意的 EVM 執行結果。

用零知識證明的方式證明池子價格在前面交易都執行完後的價格並非當初出塊者所答應的

不過在 Glamsterdam 硬分叉中會引入 Block-level Access List（BAL）的設計，在 BAL 中，區塊內容裡就會直接包含每一筆交易所修改到的變數以及修改後的值，用來證明 State Lock 承諾就會非常方便，不再需要用挑戰機制或是零知識證明。

如何咎責？

前面例子提到在 PBS 環境底下，出塊的過程牽涉到多個參與者，每個參與者都有可能導致最終承諾被打破。首先，一個承諾是如何被傳遞給不同參與者呢？社群目前制定了兩套 API：「 Commitments API」及「 Constraints API」。

• Commitments API 是給使用者請求承諾用的，而 Constraints API 則是 Relay 與產塊者之間溝通承諾用的
• 一個 Commitment（承諾）會有相對應的 Constraints，也就是對區塊內容的要求。例如 Alice 「指定她的交易要是區塊第一筆交易」是 Commitment，而相對應的「Alice 的交易必須要放在區塊的最前面」就是要履行這個承諾所要達成的要求
• Relay 透過 Constraints API 收到 Constraints 請求後，會把它記錄下來，然後產塊者會透過 Constraints API 從 Relay 那得知目前這個區塊有哪些要求必須要被遵守
• 當產塊者產完區塊交給 Relay 後，Relay 也會檢查該區塊是否有符合要求

https://eth-fabric.github.io/website/assets/images/Constraints-API.png

註：上圖中的 Gateway 是出塊者的代理人，由它來為出塊者代為接受承諾，避免出塊者因為各種不同承諾請求而導致工作量太多。

而目前 PBS 機制中，其實出塊者和產塊者雙方都是需要信任 Relay 的 — 相信 Relay 會公平的主持競標並保護雙方不被傷害。因此我們可以沿用這一個信任，由 Relay 來作為承諾被違反時的仲裁者：如果 Relay 有確實告知產塊者相關 Constraints 但最後卻有承諾被打破，那就是產塊者的問題；如果 Relay 把一個符合要求的區塊交給出塊者，但最後上鏈的區塊卻是一個有承諾被打破的區塊，那就是出塊者的問題。至於接下來 ePBS 上線後不再有 Relay 這樣的角色，這整套機制該如何調整，稍後會介紹。

Relay 做為供應鏈上的可信中間人，可以順便代為做出塊者承諾的仲裁者

MEV-Commit：MEV-Commit 鏈作為仲裁者

其他出塊者承諾協議也一樣會面臨當承諾被打破時，要如何咎責、誰來做仲裁的問題。而前一篇文章提到的 MEV-Commit 便起了一條自己的鏈來做這件事：所有承諾的「（使用者）請求」和「（產塊者或出塊者）接受」都會記錄在 MEV-Commit 鏈上，一切以鏈上資訊為準。使用者請求沒有被記錄在鏈上就不會被兌現；產塊者或出塊者接受請求後就要兌現承諾，否則押金就會被沒收。

出塊者承諾工具 — Commit Boost

Commit Boost 是一個開源、社群共同維護的出塊者承諾協議，目的是透過建立一套公開的標準，讓大家都能輕鬆且無准入地（Permissionlessly）在這套出塊者承諾協議上搭建各式各樣的承諾，避免這個市場因為缺乏競爭和高門檻而被少數人把持。

Commit Boost 制定了前面提到的 Commitments API 及 Constraints API，並基於目前 PBS 和共識層裡 Sidecar* 的設計，將出塊者承諾變成一個通用的 Sidecar。未來出塊者想要提供承諾服務，它只需要安裝 Commit Boost 的 Sidecar，就能在裡面選擇各式各樣的承諾模組來下載，而不會像現在 PBS 生態裡，如果一個出塊者要接入 Flashbot 就要下載 Flashbot 的 Sidecar，如果要接入 MEV-Commit 就要下載 MEV-Commit 的 Sidecar。

註：共識層 Sidecar 是為了避免直接修改共識層規則（例如新增或刪減某個欄位），而將資料以類似「掛載」的方式和共識層區塊並行傳輸的方式。

ePBS 對以太坊上出塊者承諾的影響

前面提到 Relay 做為被產塊者與出塊者共同信任的對象，也方便地解決了該如何咎責的問題 — 一切以 Relay 看到的為準。而 ePBS 上線（預計 2026 Q3）後，這個中心化的 Relay 角色將會消失，改為由一群被選出的驗證者（稱為 Payload-Timeliness Committee，簡稱 PTC）一起來負起 Relay 這個角色的責任。PTC 負責用投票來決定得標的產塊者是否有兌現它的承諾，也就是產塊者是否有在時限內廣播出它的區塊內容，如果廣播晚了或根本沒有廣播，那產塊者一樣要被收取它所競標的金額。

由一群驗證者組成的 PTC 取代 Relay 作為仲裁者的角色

但 PTC 只負責確保「以區塊為單位」的履行，即「這個得標的區塊是否有即時被釋出」，它們不知道一個區塊裡是否有任何出塊者承諾要被履行，例如「Alice 的交易要被收入在第一個位置」。沒有一個中心化的 Relay 角色來把關，出塊者要怎麼相信產塊者競標的區塊內容真的有符合 Constraints 的要求？

幸運的是產塊者可以利用前面提到的 Block-level Access List（BAL）來產生證明，證明一筆交易的收入，或甚至是一筆交易的執行結果。而且 BAL 也包含在產塊者的簽名內容裡，所以出塊者可以相信當產塊者提供了 BAL 證明一筆交易的收入或執行，該筆交易的承諾會獲得履行，否則它可以拿著 BAL 和產塊者簽章去罰沒產塊者的押金。如果產塊者沒辦法提供 BAL 來證明 Constraints 要求有被實現，出塊者就會直接忽略該區塊。

但這個驗證管道仍然如同當前的出塊者承諾協議，都是屬於以太坊協議之外的機制，這表示產塊者除了因為參與 ePBS 而必須在以太坊協議抵押一份押金外，它還要在其參與的出塊者承諾協議中也抵押一份押金，兩邊的押金不能共用。要等到未來像是 Protocol-Enforced Proposer Commitment（PEPC）設計被實現後，以太坊協議才會內建出塊者承諾機制，這時產塊者才不需要在多個地方都去抵押押金。想了解更多關於產塊者怎麼利用 BAL 產生證明給出塊者的設計，可以參考 這篇。

以太坊協議內的出塊者承諾方式

以上的例子都是屬於以太坊協議外（Out-of-Protocol）的出塊者承諾設計，也就是以太坊本身並不知道有這些出塊者承諾機制存在，沒有參與到這些出塊者承諾機制的驗證者也不知道他們的存在，例如當前（ePBS 之前）的 PBS 機制。協議外機制的優點是更彈性、變化改動更快，不必等半年一次的升級節奏，但缺點是要維持機制公平性和可信度，就會需要仰賴並信任中心化角色，例如 PBS 中的 Relay 角色。

那有哪些設計是可以實現「協議內」的出塊者承諾？

Inclusion List (IL)

IL（交易強制收入清單）設計的目的是用來增加協議的抗審查能力：每 12 秒都會有數個驗證者被賦予提出自己的 IL 的權利，這些驗證者可以將任意（還未被收入的）交易放入自己的清單中，下一個出塊者必須要將這些交易收入在自己的區塊中，除非總消耗 Gas 已經超過區塊上限。

因此 IL 也可以作為一個實現出塊者承諾協議的工具，但因為目前的 IL 設計並沒有辦法保證清單內的交易一定會被收入，所以這個工具的承諾並沒有辦法被 100% 保證。想了解更多 IL 的機制可以參考 EIP-7805。

註：其實 IL 可能只能算是一半「協議內」、一半「協議外」的機制，IL 本身是協議內機制，但驗證者和使用者還是要仰賴於協議外的機制來溝通並懲罰。

Protocol Enforced Proposer Commitment (PEPC)

PEPC 則是更進一步直接把出塊者承諾協議寫進以太坊協議中，由以太坊協議本身來當仲裁者。即將在 Glamsterdam 升級中上線的 ePBS 就是一個例子，由以太坊協議本身紀錄產塊者的競標、出塊者是否履行承諾，並在產塊者作惡時強制沒收押金，以及避免出塊者惡意改出另一個不同區塊。又或是像 MEV-Commit 跑一條自己的鏈來作為自己出塊者承諾協議的仲裁者一樣。

EIP-7805 比較有希望在 2026 年底或 2027 年的升級中上線；PEPC 則是對以太坊協議有更多更深層的改動，所以未必能真的實現。或至少先看看 ePBS 運行地如何，再看看是否有機會把 ePBS 的區塊內容承諾升級為更通用的承諾內容。對 PEPC 有興趣的話可以參考 這篇 Ethresearch 文章。

TEM Medium 2026 有獎徵稿

TEM Medium 目前正在進行有獎徵稿！詳情請參考：

TEM Medium 2026有獎徵稿

Special thanks to

Kimi Wu

and Kevin Chia for reviewing and improving this post

• 本文转载自： medium.com/taipei-ethere... , 如有侵权请联系管理员删除。