感謝Potuz提出了這個想法：如果提議者選擇了不正確的可審計構建者出價，插槽nn的證明者應直接使信標區塊無效。感謝Francesco在共識問題上的指導，以及Terence的反饋。
背景
在EIP-7732中指定的內建提議者-構建者分離（ePBS）是以太坊的一個擬議更新，旨在促進構建者和信標提議者之間的無信任互動。在Fusaka轉向點對點資料可用性取樣（PeerDAS）後，未訂閱所有資料塊列子網的ePBS提議者（即較小的驗證者）可能會錯誤地認為資料可用並在錯誤的頭部上繼續擴充套件。如果實施FOCIL，插槽n+1n+1的提議者同樣需要對插槽n-1n−1中的IL及時性做出主觀判斷。因此，提議者將受益於確認有效載荷滿足及時IL的證明。
（後續內容以此風格繼續翻譯）- 在 T_1T1 – 包含列表（ILs）和未封裝交易（UTs）透過點對點廣播和傳播。
- T_1T1 – 插槽 nn 的證明者凍結他們對已傳播的包含列表和未封裝交易的檢視。
- 在 T_1T1 – 一旦構建者確信他們已觀察到所有相關的未封裝交易和包含列表（大多數證明者凍結檢視中的那些），他們為獲得構建區塊的權利投放仲裁區塊標書（ABBs）（彩色矩形）。
ExecutionPayloadHeader擴充套件了一個包含列表位域，構建者在其中宣告其有效載荷遵守的包含者，以及宣告將包含其對應未封裝交易的特殊交易（STs）的未封裝交易位域。就像在 EIP-7732 中一樣，ExecutionPayloadHeader物件也應更改為僅包含承諾構建者有效載荷所需的最少資訊。 - T_2T2 – 在插槽 nn 開始時，提議者選擇一個獲勝的仲裁區塊標書，該標書至少涵蓋其對所需包含列表和未封裝交易的檢視，並將該仲裁區塊標書包含在信標區塊中。
- T_3T3 – 插槽 nn 的證明者對當前鏈頭投票。如果信標區塊丟失，或者包含的仲裁區塊標書因缺少包含列表或未封裝交易而未透過稽核，他們將指出在其當前檢視中作為鏈頭的前一個區塊。如果仲裁區塊標書透過稽核，他們將樂觀地對該區塊進行證明。這些投票仍將計入分叉選擇中的完整和空區塊 nn，因為有效載荷尚未釋出。
- T_4T4 – 當構建者透過審查傳播的證明確信信標區塊將成為規範區塊時，它會發布有效載荷。
- 在 T_4T4 – 有效載荷釋出後，可以稽核以確保其遵守仲裁區塊標書的規定。從 T_4T4 開始，所有確定包含列表和未封裝交易遵守情況所需的資訊都是可用的（執行時的遵守情況在本地檢查，插槽 nn 的證明仍在傳播）。這些資訊自然將被插槽 n+1n+1 的提議者和證明者使用，但此時任何跟蹤鏈的節點也可以直接使用。結合對資料可用性和有效載荷及時性的檢查，可以以高精度評估有效載荷成為規範區塊的可能性。
AC的剩餘角色是對有效載荷的及時性和資料可用性進行投票。未來的文章將探討在這些新的放鬆約束下，AC的角色如何進一步發展。一個額外的好處是，插槽n的包含者可以提前獲得關於插�span�n的有效載荷將遵循�易資訊p。這些是包含者不應出的易如載荷及時）。
在常規MEV-boost中式，繼是一個確保轉發為出價的構建者區塊有效性的可信方。在FOCIL下，這個有效性檢查變成了一個主觀決定，取決於中間層的及時性。一些驗證者可能更願意自行執行這個主觀檢查，查，因此ABB也可以在MEV-boost中實施（無需ePBS）。這將提高當前現MEV-boost設計的無信任任性，併為ePBS中的ABB奠勵定礎。<
關於如何處理ePBS中空區塊期間的密封交易，可以做一個單獨的說明。就像原始設計中一樣，包含在區塊A中的ST必必須保證相應的及時UT被包含在後續區塊B的區塊頂部，即使在區塊A後提出的第一個區塊未能成為規範區塊。然而，由於ePBS中區塊可以為空，一系列空區塊可能會產生大量尚未被UT履行的未完成ST。因此，一旦明確存在積壓力，，可能希望阻止信標提議者包含新的ST。針對ePBS中先前的的的間層，建議的方法是透過阻止插槽<>1n的有效載荷丟失（感謝Potuz）。這允許插槽n+1n-1；<+2滿<有效>n；n+3滿足n+2（最終趕上）。對於密封交易，這種方法可能導致在插槽nspan的交易者在插槽n+1的有效載荷構建之前就揭示UT（這將不會被包含）。因此，對於空區塊n的解決方案是指定，來自插槽n-1和n的>須在插槽n+1的UT中得到遵守，同時阻止插槽n+1的提議者包含新的ST，以使積壓不再繼續增長。。
請注意，無論選擇�擇�果要包含多個塊的UTBS，，來自特定信標區塊的相同ST集的的UT必須在有效載荷中分組，與最早信標區塊關聯的組必位於區塊頂部，依此類推。然而，每個組內的UT順序仍應遵循已揭示的頂部費用。
