tl;dr
可信的預配置協議要求提議者在簽署區塊之前驗證其承諾是否得到履行。一種簡單的方法是檢查完整的區塊體，但這會洩露構建者的區塊，這是行不通的。中繼機制可以彌補這一缺陷，但在 ePBS 之後不再需要。無需信任的解決方案是讓構建者在其出價中提交約束滿足證明。缺點是，證明生成會增加關鍵路徑的延遲，尤其是在約束演變為超出簡單交易包含範圍時。
EIP-7928 BAL提供了一種結構化的替代方案。BAL 完整記錄了塊中每次狀態寫入的情況，這些狀態寫入是執行過程的副產品，並被寫入The Block。由於每個BAL條目都具有相同的結構，因此任何預配置類型都可以簡化為對同一對象的真/假查詢。單一的驗證語言可以涵蓋任何預配置類型（包含、執行、排序、排除ETC），並且單個驗證器函數無需重新部署即可處理所有類型。新的預配置類型會轉化為新的公式，這些公式可以使用相同的基礎架構進行驗證。這在嚴格意義上改進了 Merkle 證明所能提供的保證，同時降低了延遲和複雜性。
背景
預配置允許提議者在區塊構建之前承諾，其下一個區塊將包含某些屬性。例如，用戶可能會收到預配置，保證其交易將被包含在區塊中，某個值將被寫入特定的存儲槽位，或者超過特定Threshold的支付將被包含在The Block中。
提議者做出的承諾限制了The Block的構建方式。目前，如果沒有這些限制，構建者可以自由地向提議者提交任何區塊。例如，如果引入包含性預配置，構建者就必須提交包含指定交易的區塊。
在提交區塊之前，提議者需要一種方法來驗證The Block是否滿足所有約束，以確保他們的承諾能夠得到履行。需要注意的是，承諾是面向用戶的，而約束是面向構建者的。
驗證問題
最直接的方法是讓提議者直接檢查整個區塊。如果The Block滿足約束條件，提議者就簽字。但這行不通，因為這會讓提議者無需向建造者支付任何費用就能竊取The Block。
目前，中繼機制已經解決了公平交換的問題。悲觀中繼機制中，中繼會在將區塊頭分享給提議者簽名之前，完整執行The Block，並且可以將其擴展到驗證預配置約束，作為一項可信服務。另一種方案是樂觀中繼機制，中繼在不完整執行The Block的情況下轉發區塊頭，而是依賴於追溯性故障歸因：如果構建者的區塊之後被發現無效或違反約束，則會受到懲罰。這兩種模式目前都在生產環境中存在。然而，ePBS（增強型區塊驗證系統）將中繼從關鍵路徑中完全移除，因此這兩種模式都將不復存在。
另一種無需信任的替代方案是，構建者在提交報價的同時生成約束滿足證明。最簡單的形式是針對The Block塊頭中承諾的 trie 樹根的 Merkle 包含證明。構建者可以證明某個特定交易已被包含，或者某個特定存儲槽在區塊末尾的值已設定，而無需披露完整的區塊體。
其中一個問題是延遲。證明生成發生在The Block完全構建之後。隨著預配置約束數量的增加，證明生成成為區塊構建和投標提交之間關鍵路徑上一個不容忽視的步驟。每一毫秒都會損失寶貴的構建時間，從而損害提議者的收益。
另一個問題是表達能力。默克爾證明是區塊級別的：它們可以證明某個交易被包含在區塊中，或者某個狀態槽持有特定值，但它們無法證明交易級別的狀態差異。沒有默克爾證明可以證明某個特定交易導致了某個特定狀態的改變。驗證有狀態的預配置需要完全重新執行或零知識證明，但出於隱私或延遲方面的考慮，這兩種方法都不可行。
阻止訪問列表的作用
EIP-7928將區塊級訪問列表 (BAL) 定義為區塊執行期間訪問的所有賬戶和存儲位置的完整記錄。每個BAL通過block_access_list_hash與特定的出價/區塊綁定，通過重放BAL，任何人都可以重新計算區塊的最終狀態，而無需執行實際的交易。
在 preconfs 環境中，這樣做主要有兩個原因：
1. 區塊訪問日誌(BAL)是執行的直接副產品，無需單獨的證明生成步驟。構建者在構建The Block時就已經擁有BAL記錄了The Block期間發生的每一次狀態寫入：存儲槽值、餘額變化、隨機數遞增和代碼更新，每項都帶有block_access_index標籤，用於捕獲全局寫入順序。這足以讓提議者直接驗證狀態結果的任何屬性：存儲槽的值被寫入了什麼、賬戶餘額是否超過了Threshold、隨機數是否遞增、兩次寫入是否按特定順序發生，或者合約是否被修改過。所有這些檢查都不需要交易檢查。
2. BAL可以在不洩露區塊內容的情況下進行驗證。重建區塊需要實際的已簽名交易及其輸入，而BAL省略了這些信息。僅檢查BAL 的提議者無法獲得任何信息，使其能夠在不向區塊創建者支付費用的情況下重建並重新提交The Block。然而，如果所有交易都來自公共內存池，那麼有決心的提議者原則上可以僅憑公開信息重建區塊（但那樣的話，他們完全可以在沒有區塊創建者BAL的情況下自行構建相同的區塊）。具有私有訂單流的區塊無法重建。
從交易承諾到結果預會議
當前的預配置方法對特定的已簽名交易做出承諾。結果預配置則不再關注交易，而只關注狀態承諾。
在當今的意圖機制中，你預先設定一個結果，例如“用X至少交換Y ”，求解器競相尋找自定義解決方案，然後智能合約最終驗證意圖是否得到滿足。結果預配置在提議者層應用了相同的模型。當提議者承諾“對槽位S首次寫入值為V ”時，他們承諾的是一個狀態結果，而不是一個執行路徑。構建者可以通過任何有效的交易序列來滿足此約束，因為該約束並未說明是哪個交易執行了寫入、由誰發送的、消耗了多少 gas等等。
簡而言之，提議者表達其區塊的期望結果，建造者競爭尋找任何能夠實現這些結果的有效執行路徑，提議者在提交The Block之前（並且不會洩露The Block內容）驗證結果是否已實現（通過BAL ）。
統一約束語言
BAL是一個單一的結構，任何結果預配置類型都可基於此進行驗證。這與當前預配置的工作方式截然不同，在當前情況下，每種類型都是一個獨立的設計問題：包含預配置需要一種證明格式，排序約束需要另一種，執行預配置又需要另一種。每增加一種新類型，都需要為提議者提供新的驗證邏輯，並需要新的鏈上懲罰機制。添加新的預配置類型意味著需要對整個技術棧的每一層進行協調升級。
由於每個BAL條目都共享相同的四個字段（地址、字段類型、寫入的值和排序索引），因此驗證任何結果的 preconf 都簡化為相同的真/假問題：是否存在具有這些屬性的寫入？此地址是否存在？寫入A是否發生在寫入B之前？
一階邏輯 (FOL) 是一種形式語言，專門用於對一組固定的對象進行真/假判斷。它易於理解，並且已知在有限結構上是完備的：任何可以用純英語表達的關於固定模式BAL的布爾屬性都可以用一階邏輯公式表示。
實際結果是隻需要一個驗證器。它以一階邏輯公式和BAL作為輸入，並返回真或假。驗證器函數只需構建一次（在正常競價流程中位於提議方的邊車函數中，在爭議解決時位於懲罰合約中），之後無需更改。新的預配置類型意味著需要編寫一個新的一階邏輯公式，而無需部署新的基礎設施。
該語言包含兩類基本運算。比較運算是葉子節點：字段相等性、不等性以及順序檢查（ == 、 >= 、 <ETC），應用於匹配條目中的值。邏輯連接詞構成結構：“存在一個滿足……的條目”、“兩個條件都成立”以及“此條件不成立”。這與使用單一門類型構建任何邏輯電路的原理相同，只需最少的基本運算即可獲得無限的表達能力。
去中心化應用（DApp）需要代表用戶計算公式。這包括確定哪些存儲位置會受到用戶交易的影響，以及哪些存儲位置需要檢查餘額（BAL）。對於算術約束（例如“餘額增加Y ”、“價格在5%以內”、“nonce 遞增”），DApp 會直接向公式提供這些提示，這意味著 DApp 語言本身無需支持算術運算。具體來說，如果 Alice 的 nonce 為5 ， USDC餘額為500 ，並且她希望至少收到2000 USDC，那麼 DApp 會讀取初始狀態，計算出 nonce 為6且餘額為2500 ，並構建一個公式，該公式只需檢查nonce == 6且balance >= 2500 。
會前模式和一級用戶體驗結果
以下每個模式都是BAL 的一個公式。所有模式均由同一驗證器處理。請注意，這些模式僅供參考，可能並不完整。在以下公式中， (A, Nonce)和(A, Balance)分別指賬戶A的 nonce 和ETH餘額字段； (C, S)指合約C中的存儲槽S ； V是預期值。這些字段類型與BAL條目中的字段類型直接對應。
保證包含。Alice希望她向 Bob 轉賬的ETH被包含在下一個區塊中。Alice 的 nonce 遞增確認了她的交易已執行，而 Bob 的餘額增加確認了付款已到賬。這兩個寫入操作必須共享相同的block_access_index ，以確認它們來自同一筆交易。dapp 在構建公式之前，會從父狀態根計算絕對的 post-state 值。
there exists a write to ( Alice, Nonce ) with value == n+ 1 [call this e1] AND there exists a write to ( Bob, Balance ) with value > = bob_pre_balance + amount AND index == e1.index區塊頂部。用戶的交易應該是The Block中的第一個用戶交易。block_access_index 是按交易分配的block_access_index其中索引0保留給執行前系統合約寫入（例如 EIP-4788 信標根更新），用戶交易的索引從1開始。這是目前最強的排序保證，因此定價也應相應較高。
there exists a write to (Alice, Nonce) with value == n+ 1 AND index == 1 AND there exists a write to (C, S) with value == V AND index == 1合約優先訪問權。用戶希望成為第一個與特定合約交互的人，但不想支付區塊頂幣的費用。一個經典的例子是鑄造 NFT：第一個調用鑄造函數的人優先，其他一切都無關緊要。檢查範圍完全限定於合約C的條目，這使得構建者可以完全自由地決定其他所有內容的順序。
there exists a write to (C, S) with value == VAND its index is less than or equal to every other write to C同槽位意圖結算。用戶簽署一個意圖，“將我的X ETH兌換成至少Y USDC”，但未指定如何實現。構建器會同時包含用戶的意圖交易和求解器的執行交易。公式中的順序約束確保意圖執行在求解器支付之前完成。至關重要的是，健康的構建器競爭對於提升用戶收益至關重要。
there exists a write to ( A, Nonce ) with value == n+ 1 [call this e1] AND there exists a write to ( A, ETH_Balance ) with value < = eth_pre_balance - X AND index == e1. indexAND there exists a write to ( A, USDC_Balance ) with value > = Y [call this e2]AND e1.index < e2.index執行結果預配置。以往，保證特定的執行後狀態需要對 EVM 執行進行零知識證明。而使用 BAL，隨機數遞增即可確認用戶事務已運行；存儲槽檢查即可確認預期的狀態變更。兩次寫入必須共享同一個索引，以確認它們來自同一事務。無需重新執行。
there exists a write to ( A, Nonce ) with value == n+ 1 [call this e1] AND there exists a write to ( C, S ) with value == V AND index == e1.index上述模式可以自由組合。通過在 nonce 檢查中添加index == 1 ，可以將塊頂保證疊加到同槽意圖結算之上。執行結果可以與排序約束結合使用。上述任何組合都是有效的公式，並且使用相同的驗證函數進行驗證。
使用 ePBS 進行會前結果評估
由於結果預配置的範圍限定於結果而非特定交易，因此滿足這些預配置就形成了一個市場。多個搜索者可以獨立競爭來滿足任何給定的預配置。構建者選擇最佳組合。任何一方都不需要了解其他方的執行策略。以下流程圖展示了這如何融入 ePBS 後的競價流程。
請注意，構建者簽署的約束承諾並不參與鏈上流程。它的作用在於協議之外：如果構建者簽署了約束，然後提交了違反這些約束的BAL ，那麼它就生成了自身過錯的加密證明，外部懲罰或信譽系統可以據此採取行動。
約束驗證步驟在提議者的邊車程序中運行，邊車程序是鏈下實現的，其驗證邏輯與懲罰合約中部署的驗證邏輯相同。兩者在構造上是等價的，因此提議者確認的檢查與懲罰合約在爭議發生時運行的檢查相同。
另請注意，在 ePBS 規範中，構建者的出價包含的是block_hash承諾，而不是頭部本身。因此，提議者需要建立從BAL → block_access_list_hash → 頭部 → block_hash → 出價的信任鏈。
侷限性
BAL並不能證明底層交易具有有效的簽名。構建者可以構造一個滿足所有結果預配置檢查的BAL ，但該 BAL 對應的卻是無效或偽造的交易。當有效載荷被揭露時，它將無法通過驗證，提議者也將失去其席位。幸運的是，在 ePBS 之後，提議者仍然可以無條件地獲得競標金額。
如果沒有協議外懲罰機制來抑制這種構建者行為，結果預配置可能會進一步刺激構建者行使他們的自由選擇權，因為違反預配置承諾可以獲利。讓構建者甚至多個參與方承諾遵守約束條件，是朝著建立這種機制邁出的一步。
BAL作為爭議證據
如果預協商爭議進入鏈上裁決階段，則每個約束均可獨立提出異議。提出異議的一方需提供被違反的約束、提議者在該約束上的簽名、構建者的簽名承諾、 BAL（區塊訪問列表）以及The Block塊頭。懲罰合約會使用block_access_list_hash對BAL進行身份驗證，並運行與提議者邊車在正常驗證期間運行的相同的驗證器。如果驗證器返回 false，則證明存在違規行為。
一階邏輯公式結構非常適合零知識證明。對固定模式BAL 的查詢進行證明的成本遠低於對任意 EVM 執行的證明成本，因此針對已提交的BAL根進行零知識證明是一個可行的未來優化方向。
通往聖殿之路
本文所述設計完全違反協議。提案者和構建者的承諾通過經濟激勵和違反協議的懲罰機制來強制執行。即使區塊違反了預配置結果，從網絡的角度來看，它仍然是一個有效的區塊。
實現協議內承諾是可行的。PEPC 指出了協議強制提案人承諾的必要性，但承諾的表示形式仍未確定，例如是否使用 EVM 執行、SNARK 或其他結構。此外， PEPC還指出了一個數據可用性問題：第三方如何以驗證者可驗證的方式提供承諾證明？BAL 有望解決這兩個問題，因為它本身就是The Block塊頭中承諾的一等對象，無需單獨的證明交付機制。FOL 約束語言簡潔且定義明確，驗證器是一個可在共識層部署的單一函數。協議無需驗證者重新執行承諾代碼，而是可以直接使用經過認證的BAL來驗證 FOL 公式。
要使之符合協議規定，還需要幾個其他部分協同工作：
具有約束力的承諾廣播。提案方的約束條件需要在競價過程開始前以不可更改且可追溯的方式發佈。這類似於提案承諾廣播（PTC），但針對的是約束條件。
投標文件中包含BAL和標頭。為了使提案方在簽署前能夠核實約束條件，建設方必須在投標文件中包含BAL和標頭，而這些文件目前並非 ePBS 規範的一部分。
無效的BAL將對建築商處以處罰。如果投標時提交的BAL與最終公佈的The Block不符，或者公佈的區塊無法驗證，則應處罰建築商。在ePBS實施後，建築商已被要求提供抵押品，因此大部分繁重的工作已經完成。
概括
ePBS 不需要中繼，因此重新引入中繼作為可信的預配置驗證器並不理想。默克爾證明提供了一種無需信任的替代方案，但會增加關鍵路徑的延遲，並且無法表達有狀態或排除約束。BAL 解決了這兩個問題：它們作為區塊執行的副產品生成，不會增加延遲；並且通過將承諾從事務級轉移到意圖級，任何預配置類型都可以簡化為基於相同BAL結構的公式。這種可表達性不需要在關鍵路徑上使用零知識證明，並且添加新的預配置類型不需要對驗證器或懲罰基礎設施進行任何更改。
