我們的共識機制引起了許多問題。 我們的設計是我們投入了大量思考的結果，我們相信未來會有許多協議使用這種設計。 BULK 通過首先使用基於 Minisketch 的調解（這是一種緊湊的草圖算法，能有效地同步同儕之間的訂單差異）來達成快速共識，這樣可以在每個時間點上達成收到的訂單集的共識。 BULK 並不是立即就同意整個鏈狀態，而是依賴其確定性執行，這樣每個節點可以在後續處理相同的已達成共識的訂單，並獨立達到相同的結果狀態。 在後續的時間點上，系統通過 BFT 風格的共識達成狀態共識，確保所有節點都收斂到相同的最終狀態。 這種分時點模型將快速的訂單共識與較慢的狀態最終確定分開，這使我們能夠快速執行（20 毫秒），同時保持確定性的安全一致性。 這些過程是為了支持一個巨大的訂單簿而構建的。雖然它的運作方式與標準的應用鏈或 L1 不同；它是一個狀態機，能夠使 BULK 上的任何行動都可以進行加密驗證、可重播並存儲在賬本中。 這一切對你的交易體驗有什麼重要性？ 1. 你可以選擇確認的承諾級別 - (a) minisketch 接受（8 毫秒），(b) 執行（25 毫秒）和 (c) 狀態最終確定（40 毫秒）；任何對延遲敏感的參與者，如做市商，將擁有最佳的體驗，因為交易幾乎是瞬間被確認的。 2. 你可以選擇要發送訂單的節點（MCP），因此不會對你的訂單流進行節點審查或夾擊攻擊。 3. BULK 是網絡中的中立參與者 - 所有的驗證者決定你的訂單、匹配結果和資產變更的處理方式。 4. 你可以重播和驗證鏈上發生的事情 - 最佳用例是在清算期間；驗證你沒有被挑選進行掃蕩或你的訂單被忽視。 5. 韌性性能 - 作為一個狀態機；容錯是自然而然的。10 月 10 日的事件教會我們，單一機器在重負載下可能會崩潰。隨著多個節點參與處理訂單簿，你的體驗永遠不會下降。 還有更多模塊（執行器、訂單廣播、風險模型等）將與 bulk-agave 一起上線，我可以在不久的將來介紹這些。這篇文章希望能回答我們從共識極客那裡收到的許多問題。 感謝你對此事的關注！