一筆交易若要在多鏈場景下被其他鏈、橋接或應用視為「已確認」,通常需經過「提交 → 排序 → 共識確認 → 狀態可見」這一可重複流程。Espresso Network(ESP) 作為共享確認與結算基礎層,負責接收 Rollup 排序器提交的區塊,並由驗證者網路透過 HotShot 共識機制於數秒內完成 BFT 背書,隨後將 Espresso-confirmed blocks 對下游開放查詢。
此流程解決了確認時序問題:應用無需等候以太坊 L1 完成最終結算,即可取得可驗證的序列與狀態視圖;L1 結算仍可依橋接規則進行。了解各階段的觸發時機及確認回傳方式,有助於明確跨鏈讀取狀態的邊界。
在交易進入 Espresso 確認流程前,相關系統必須處於可整合狀態:目標環境已連接 Espresso;存在授權排序器(或等價的區塊構建角色);交易已被該環境的執行與排序規則接納。Espresso 不取代各環境的執行層,而是針對排序器輸出的交易流進行去中心化確認。
| 準備項 | 核對條件 | 未就緒時的影響 |
|---|---|---|
| 環境整合 | Rollup / 應用是否已連接 Espresso | 區塊無法進入確認層 |
| 授權排序 | 是否有排序器可向 Espresso 提交區塊 | 無法啟動提交與排隊 |
| 交易接納 | 交易是否已被該環境 mempool / 排序規則接收 | 無區塊可進行確認 |
| 下游消費方 | 橋、應用或求解器是否訂閱確認視圖 | 確認完成但跨環境無法讀取 |
如上所示,秒級確認需「整合 + 授權提交 + 下游讀取」三者同時具備。用戶端一般僅感知「交易已提交至某 Rollup」,而系統內部則需將該交易編入即將送往 Espresso 的區塊。
當用戶或應用向 Rollup(或其他執行環境)提交交易時,即觸發此流程。交易首先進入該環境的接收與排隊機制,經授權排序器依本地規則排序、打包成區塊或批次,然後提交至 Espresso。Espresso 端接收的是排序器產生的區塊流,而非單筆交易執行。
在提交與排隊階段,介面可能迅速顯示「已接收」或「預確認」,這屬於各 Rollup 排序器的本地回饋;Espresso 層級的確認尚未發生。系統內部動作為:排序器鎖定本批次順序,生成可提交區塊,並透過整合接口送出。此流程可隨時重複——新交易到達即重新打包、提交。
若排序器發生延遲、審查或未按協議提交,交易將滯留於本地隊列,下游仍無法看到 Espresso 級 Finality。排序權是否集中,屬於 共享排序層對比的架構議題;本節僅關注「一旦提交後續確認如何完成」。
區塊進入 Espresso 後,驗證者網路運行 HotShot 共識機制:於權益證明(PoS)與拜占庭容錯(BFT)架構下,就區塊順序與數據可用性(DA)迅速達成共識。HotShot 強調在網路狀況良好時快速確認。官方資料顯示主網典型確認時延約為數秒。
當足夠權重的驗證者對提議區塊完成投票,即觸發確認。達到門檻後,該區塊成為 Espresso-confirmed block,序列與承諾在共識層固定。各 Rollup / 應用環境仍需根據已確認序列執行確定性狀態轉移;Espresso 本身不負責執行業務邏輯。
| 流程階段 | 觸發條件 | 系統內部動作 | 用戶 / 應用端可見變化 |
|---|---|---|---|
| 提交 | 排序器打包並送出區塊 | 區塊進入 Espresso 待確認路徑 | 多數顯示「處理中 / 預確認」 |
| HotShot 確認 | 驗證者投票達 BFT 門檻 | 區塊獲得 Espresso Finality | 可查詢 Espresso 確認視圖 |
| 下游讀取 | 橋 / 應用訂閱確認結果 | 跨環境依確認序列推進邏輯 | 跨鏈動作可依確認狀態啟動 |
| L1 結算(後續) | 按橋及合約規則上鏈 | 向以太坊等 L1 提交對應批次 | L1 最終結算完成(時延較長) |
如上表所示,「秒級確認」與「L1 最終結算」為分離流程:前者由 HotShot 共識於 Espresso 層完成;後者則依原有橋接設計進行,協議層可規定僅 Espresso 確認的區塊可於橋接 L1 上結算。

圖 1. Espresso 確認主流程:用戶/應用提交 → Rollup 排序器打包 → HotShot 驗證者確認 → Rollup/橋/應用消費 Finality。
驗證者參與確認需質押並受協議激勵;ESP 質押與協議費說明 ESP 在驗證者質押與費用支付中的作用,此為確認層長期運作的經濟基礎,並不改變流程時序。
HotShot 完成確認後,Espresso-confirmed blocks 於數秒內即成為可查詢視圖。Rollup 節點、批量提交者、橋接組件、消息協議、求解器及其他鏈上應用,可透過查詢服務或事件流讀取已確認序列與狀態承諾,據以更新「該環境已確認狀態」的判斷。
回傳方式並非將執行結果推送至所有鏈,而是提供可驗證的共享真相來源:誰先讀取確認,誰即可依自身規則推進跨環境邏輯。協議層限制確保:橋接 L1 結算時,僅有與 Espresso 確認一致的區塊可被接受,避免排序器事後改寫已確認序列。對用戶而言,體驗為跨鏈操作更快可用;對系統而言,則為確認層先於 L1 結算提供可組合的中間事實。
若僅依賴以太坊 L1 最終結算,Rollup 批次須等 L1 完成最終性後,橋與跨鏈應用才視狀態為完全安全;此等待通常需十餘分鐘。Espresso 路徑則於排序器提交後先取得秒級 BFT 確認,下游可提前讀取確認狀態,L1 結算則作為後續安全錨點持續存在。
| 維度 | Espresso 確認路徑 | 僅依賴以太坊 L1 最終結算 |
|---|---|---|
| 確認主體 | HotShot 驗證者網路(BFT) | 以太坊 L1 共識最終性 |
| 典型時延 | 約數秒 | 通常需十餘分鐘 |
| 下游可讀時機 | Espresso-confirmed 後即訂閱 | 多數於 L1 最終性後才推進 |
| 排序器關係 | 可保留本地排序器,確認層去中心化背書 | 批次直接面向 L1,節奏隨 L1 |
| 歧義約束 | 可強制結算批次需匹配 Espresso 確認 | 依賴 L1 合約及證明窗口 |
上表顯示,差異在於「誰先給出可依賴的序列承諾」及「橋與應用何時啟動跨環境動作」。Espresso 並不取代 L1 結算,而是在中間插入可重複的快速確認層。

圖 2. Espresso 路徑與僅等 L1 結算路徑對比:左為秒級 HotShot 確認後供橋/應用讀取,右為待 L1 最終性後再行動。
失敗點可能出現在提交、共識與下游消費各環節。排序器若遭審查、當機或延遲提交,交易無法進入 HotShot;若驗證者網路未達投票門檻,確認時延拉長或暫停;下游未正確訂閱 Espresso 視圖時,即使用戶端顯示成功,跨鏈邏輯仍可能依舊時序等待。
結構性風險還包括:確認層安全依賴質押分布與 BFT 假設;Espresso Finality 與 L1 最終結算為不同安全邊界,應用若誤將秒級確認等同 L1 最終性,則橋接及清算參數將出現偏差;整合或查詢組件缺陷則導致「已確認但無法讀取」。此處風險僅針對機制邊界,無涉投資建議。
Espresso Network 上的秒級確認為一可重複流程:交易先於 Rollup 環境被接納並由授權排序器打包提交,HotShot 驗證者於數秒內完成 BFT 確認,Espresso-confirmed blocks 隨即供 Rollup、橋與應用讀取,L1 最終結算則依匹配規則後續進行。拆解提交、確認與回傳的觸發條件及失敗點,有助於將「秒級 Finality」正確認知為一種確認時序設計,而非單次事件結果。
Espresso Network 是面向多鏈及應用環境的共享確認與結算基礎層。各環境保有自身執行與排序規則,將區塊提交至 Espresso 後,由驗證者透過 HotShot 給出可供其他鏈與橋查詢的快速 Finality。
授權排序器將區塊提交至 Espresso 後,驗證者執行 HotShot 共識,當投票達 BFT 門檻即確認區塊順序與數據可用性。官方說明典型確認時延為數秒,下游無需等以太坊 L1 最終結算即可查詢確認視圖。
HotShot 為 Espresso Network 採用的拜占庭容錯共識協議,專為驗證者間就區塊排序與可用性快速達成一致而設計。其強調在網路順暢時盡速確認,為 Rollup 及應用提供秒級 Finality 背書,並不負責執行交易本身。
跨鏈橋、消息協議與求解器可直接查詢 Espresso-confirmed blocks,取得整合鏈的已確認狀態,無需等待 L1 完成最終性。提前確認後,跨環境動作可更早啟動,同時協議層亦可約束上鏈結算批次須與 Espresso 確認一致。
主要風險包括排序器提交失敗或遭審查、驗證者共識未及時達標、查詢及整合組件錯誤,以及混用 Espresso Finality 與 L1 最終結算導致的安全邊界誤判。確認層亦依賴質押分布與 BFT 假設;任一環節中斷即無法完成「秒級確認」路徑。





