BAL（EIP-7928）是什麼？為什麼會被視為並行執行的必要條件

BAL（EIP-7928）在 Glamsterdam 討論中經常被稱為「並行執行前置條件」，其核心意義並非立即讓所有事務並行處理，而是將狀態訪問關係從隱性假設轉化為可驗證的顯性約束。唯有約束明確，調度才能建立在穩固基礎之上。

這一約束層與 Glamsterdam 升級全景 的升級目標直接相關，並與 ePBS（EIP-7732）機制 形成互補：ePBS 負責出塊協作邊界，BAL 則聚焦於執行約束邊界。Glamsterdam 對 DApp 的影響 進一步說明約束層變化如何影響應用效能預期及發佈節奏。

BAL（EIP-7928）是什麼？

BAL 對應區塊級訪問列表（Block-Level Access Lists），用於記錄單一區塊執行過程中所訪問的帳戶及儲存位置，並可包含執行後的狀態結果資訊。其設計目標並非取代執行引擎，而是為執行引擎提供更早且明確的衝突判斷與資料準備依據。

傳統串行執行的優勢在於一致性簡單，但在高負載情境下效率上限明顯。若要實現並行執行，首要解答「哪些事務會互相衝突」這一問題。BAL 的價值，在於將衝突識別由執行時發現前移至可規劃的前置判斷階段。根據 Ethereum.org 路線圖 及 EIP-7928，BAL 被列為 Glamsterdam 階段的關鍵提案之一。

以太坊為何需要 block-level access lists？

隨著區塊內容日益複雜，若狀態讀寫關係僅於執行時動態揭示，客戶端難以提前規劃執行路徑。即使硬體資源充足，也可能因衝突回退及重複調度導致實際效能不穩。

block-level access lists 的意義在於降低「執行時才發現衝突」的風險。有了明確的執行前約束，客戶端可進行資料預備、任務拆分及衝突隔離，減少隨機波動。對於索引服務、歸檔節點等高度依賴狀態讀取的角色，提前獲知訪問關係也有助於優化 I/O 規劃。

上表說明 BAL 改變的是「資訊可得性」，而非直接決定最終吞吐量。

BAL 如何協助客戶端識別衝突並優化調度？

客戶端可根據訪問列表做出兩類決策：一是劃分「可並行集合」，二是保留「必須串行路徑」。即使無法全面並行，也可先提升低衝突部分的效能，逐步擴大可並行範圍。

從工程實踐角度來看，BAL 帶來的不是單次峰值突破，而是執行行為的可預測性提升。對節點運維團隊而言，可預測性通常比短期峰值更具價值，因為這直接關係到 SLA 及異常處理能力。測試網中的衝突率與回退率變化，是評估 BAL 成效的重要依據。

圖 1. BAL 機制示意：區塊級訪問列表如何支援衝突識別與並行執行調度。

BAL 與並行執行之間的關係為何？

BAL 並非並行執行的「替代品」，而是並行執行的「前提層」。並行執行仍需依賴客戶端實作、調度策略及狀態管理等多重協同。若無前置約束，強行並行反而會加劇不確定性。

更精確的說法是：BAL 讓並行執行從概念討論落實為可工程推進的任務。它解答的是「先決條件是否具備」，而非「最終效能已經達成」。即使未來引入更進取的並行策略，BAL 所提供的訪問約束仍是衝突治理的基礎依據。

BAL 對開發者與應用團隊有何意義？

開發者需更加關注狀態訪問模式。高頻寫入同一狀態、跨合約複雜依賴、批次事務耦合等設計，可能在新約束下展現出不同的執行特性。應用上線前應補充執行路徑測試，而非僅檢查功能正確性。

產品團隊也應調整效能溝通策略。升級後用戶體驗改善不一定呈線性，特別是在生態尚未完全適配時。更穩健的做法是採用分階段指標：確認穩定性、失敗率、延遲分位數，而非僅宣傳平均值；指標重設及灰度發佈仍應與應用適配框架保持一致。

BAL 的實施邊界與潛在挑戰為何？

第一項挑戰是跨客戶端實現一致性。不同執行客戶端對訪問列表解析及調度策略可能有細節差異，需透過測試網對比及跨客戶端回歸持續收斂，並保留帶時間戳的指標快照。

第二項挑戰是生態理解成本。開發團隊若忽略狀態訪問結構，升級後可能出現效能偏差；歷史合約亦未必以友好訪問模式編寫，遷移與適配需投入工具與週期。

第三項挑戰是監控體系升級。運維團隊需新增與訪問約束相關的監控指標，才能判斷問題屬於資料準備、調度衝突或執行引擎瓶頸。若無監控升級，機制價值難以完全釋放。就 節點升級準備清單 而言，BAL 相關日誌及衝突回退率應納入驗收項目；在 Glamsterdam 與 Dencun/Fusaka 對比 框架下，這類挑戰屬於結構層變更的特有風險，不宜簡單套用容量升級經驗。

總結

BAL（EIP-7928）聚焦於執行秩序：將狀態訪問關係前置、結構化衝突識別，並將調度決策由臨場反應推進至可驗證規劃。它不會單獨決定升級成敗，卻是並行執行能否穩定落地的關鍵，是 Glamsterdam 執行層的核心約束機制之一。

FAQ

BAL（EIP-7928）是不是並行執行本身？

不是。BAL 是並行執行的前置約束層，負責提供衝突識別的基礎。並行執行還需依賴客戶端實作與調度策略等配套能力。

BAL 為什麼會影響實際效能體驗？

因為它將狀態訪問關係提前顯性化，客戶端得以更早進行資料準備與任務分組，減少執行時的衝突回退，提升執行穩定性。

BAL 和 ePBS（EIP-7732）如何分工？

ePBS 聚焦於出塊協作邊界，BAL 則專注於執行約束邊界。兩者分別作用於不同層級，在 Glamsterdam 中相互補足。

DApp 團隊應如何因應 BAL 的引入？

應優先審查狀態訪問模式及高頻交易路徑，補充升級前後的執行行為測試，並更新效能監控及告警閾值，避免沿用舊有執行假設。

BAL 能否確保所有交易都能並行處理？

不能。BAL 提供衝突識別與調度依據，但高衝突交易仍需串行處理。並行範圍取決於訪問模式、客戶端實作及網路負載特性。