共識不是只有快：
為什麼新協定要重寫「最後確認」

Minimmit 與 Multimmit 的問題不只是怎麼更快出區塊，而是如何在不同網路與故障假設下，更早知道一筆決定能不能被安全地推翻。

來源：Zero Knowledge Podcast Episode 408 ｜原始發表日期：2026 年 8 月 5 日

SCROLL

PART 1 ｜共識在承諾什麼

看到區塊，不等於已經拿到不可逆的答案

Patrick O'Grady 在節目中把共識拆成一個常被混在一起的問題：系統可以很快提出下一個區塊，但參與者何時能足夠有把握地說「這個順序不會再被改寫」？前者關係到吞吐與延遲，後者才是最終確認（finality）的安全承諾。

這也是為什麼共識協定的比較不能只看每秒交易數或區塊間隔。它還取決於網路何時延遲、多少節點可能故障、誰負責傳播資料，以及在異常條件下系統是停下來等待，還是可能做出衝突決定。

共識不是替所有人「投票」。它是在不完全可信的網路裡，讓足夠多的參與者對同一段歷史形成可驗證的共同承諾。

PART 2 ｜從框架到積木

O'Grady 描述 Commonware 時，刻意不用一個預先打包好的區塊鏈 SDK。它更像一組 Rust 的可組合 primitives：網路、儲存、執行與共識層可以被替換或直接組裝。這種設計不是免費的便利；它要求使用者更清楚自己要承擔什麼選擇。

訪談的核心判斷是，通用框架會把常見決策預設好，但當協定需要新的資料傳播方式、不同的故障模型或特殊效能路徑時，那些預設可能反而成為限制。可組合不保證比較安全或比較快，它保證設計上的責任不被藏在抽象層後面。

預設框架快開始、少決策，但也繼承了框架的假設。

可組合積木每層可替換，能為特定協定調整資料與網路路徑。

工程責任彈性增加時，測試、安全界線與整合成本也要自己負責。

PART 3 ｜ Minimmit 的問題

節目將 Minimmit 放在一個明確脈絡：傳統 BFT 設計常把區塊提議、投票傳播與最終確認綁成同一條節奏。研究者想知道，若把區塊生產和確認訊號重新安排，能否在維持可驗證安全條件下，縮短使用者等待確定結果的時間。

這不是宣稱「延遲已被消除」。任何快速確認都依賴協定列出的網路與故障假設；在假設不成立時，協定可能需要退回較慢的路徑，或寧可暫停也不產生不一致結果。讀者應把論文與實作中的前提當成主張的一部分，而不只是看標題中的速度。

資料可得性參與者能不能取得應該投票的資料？

故障門檻多少節點作惡或離線時，安全承諾仍成立？

網路時序同步、部分同步或長時間延遲，會改變協定能保證什麼。

PART 4 ｜ Multimmit 與更細的確認粒度

Multimmit 延伸這條研究方向：在區塊還沒有完全以單一方式結束前，是否能讓系統對其中某些延伸、批次或承諾取得更快的確認訊號。這類設計的目標是降低等待時間，但同時必須避免讓不同節點對「哪些內容已確定」產生模糊、無法驗證的理解。

因此，這不是把 finality 變成一個行銷字。真正需要檢查的是證明由誰產生、其他節點如何驗證、衝突時誰會拒絕什麼，以及協定在網路壓力下的最壞情況。O'Grady 的觀點是，工程實作與共識研究必須來回校正，而不是把論文和系統分成兩個互不相干的世界。

快的區塊不是終點。
能在壞條件下仍說清楚「何時算數」，才是共識的工作。

這是對 Episode 408 訪談主題的閱讀整理；Minimmit、Multimmit 與其他協定的效能與安全結論，都應連同其論文、實作版本與假設分別檢驗。

Zero Knowledge Podcast Episode 408 保留 Patrick O'Grady 對 Commonware、Simplex、Minimmit、Multimmit 與共識工程的完整討論。