Airbender Prime：關注最慢的區塊

分析 | 2026年10月17日

ZKsync在10月13日公布的測試稱，一張GPU證明7,200個區塊，每個均低於12秒。

值得追問的工程問題，是如何使用更快證明器帶來的時間餘裕。Open Market Notes 分析三種選擇：縮短等待、吸收突發任務，或要求更多實作達成一致。下文計算是原創的假設示例，並非 Airbender Prime 的實測資料，也不是對已公布測試的獨立重現。

先決定計時在哪裡結束

以太坊路線圖描述了12秒的出塊節奏，並區分證明生成與驗證。

在我們提出的服務測試中，完整任務可用時開始計時，所需結果被接受時停止。排隊、證明、傳輸和驗證分別記錄。證明階段縮短，可以給其他環節留下時間，但不能據此確定它們實際需要多久。單憑出塊間隔，也無法確定服務接受結果的截止時間；這項條件必須明確寫出。

一個慢任務可能拖延後面的任務

設想五個相互獨立的任務，分別在第0、12、24、36和48秒到達。一個工作單元按到達順序處理，中途不搶占。處理時長依次為8、8、20、8和8秒。每個任務的截止時間均為到達後12秒。忽略傳輸、驗證、啟動及其他全部開銷；恰好在截止時刻完成算作準時。

完成時刻依次為第8、20、44、52和60秒，對應截止時刻為第12、24、36、48和60秒。第三、第四個任務逾時，儘管平均處理時長只有10.4秒。第四個任務只需八秒工作，卻承接了第三個任務造成的等待。第五個任務剛好準時完成，沒有為任何被省略的開銷留下餘裕。

這個例子並不估計真實系統的逾時率。它只分離兩個概念：處理任務本身花費的時間，以及任務到達後經過的時間。調整任務順序、允許搶占或增加工作單元，都會形成不同的實驗。這些選擇應當可見，而不應藏在平均值裡。

備用容量與必須達成的一致並不相同

以太坊基金會的研究主張，zkVM及其執行的狀態轉換實作都應保持多樣性。

現在設想兩條明確屬於假設的接受規則。第一條接受兩個工作單元中最早產生的有效結果；第二條要求兩個指定的獨立實作都提交有效且一致的結果。假設候選區塊相同，結果分別在第八和第十三秒可用，且沒有其他開銷。第一條規則在第八秒接受結果；第二條最早也要等到第十三秒。這只是服務策略示例，不是在描述當前以太坊共識。

因此，在兩種設計中，額外工作單元承擔的職責不同。第一種可以用它補上遲到的結果；第二種則把它的結果納入必要條件。機器更多，本身並不能說明哪些結果必須一致。任何速度比較都應明示接受規則，包括缺少必要結果時，任務是否仍未完成。

測試突發任務，也披露未完成的工作

我們建議按明確規定的到達時間表，重播固定的區塊序列，並納入突發任務。保留排隊歷史，而不是在每個區塊開始前重設工作單元。說明可用硬體、排程規則、截止時間和接受條件。在啟用預期的備援或實作多樣性要求後，執行同一序列。

分別報告截止前被接受的結果、遲到結果和未完成任務，並展示突發任務後佇列需要多久才能恢復。不要僅因為任務沒有完成時間就把它刪去：排除這些工作，可能讓一個吃力的服務顯得更快。營運結果應與安全評估分開。

設計選擇在於如何使用省下的時間。更短的等待、應付難處理序列的儲備，以及額外一個必須取得的結果，是對同一份餘裕的不同用途。下一次有價值的示範，應把這種分配寫清楚，並展示選定的截止時間能否經受由此形成的佇列。