熱門話題
#
Bonk 生態迷因幣展現強韌勢頭
#
有消息稱 Pump.fun 計劃 40 億估值發幣,引發市場猜測
#
Solana 新代幣發射平臺 Boop.Fun 風頭正勁
總結 MonadBFT 的突破
昨天 Category Labs 發佈了 MonadBFT 論文,描述了將在主網上為 Monad 提供支援的共識機制。
MonadBFT 是共識研究的一個重大進展,因為它是 Pipelined HotStuff 第一次對尾部分叉產生抵抗力。
當錯過的 slot 導致前一個提案被丟棄並重新挖掘時,就會發生尾部分叉。這在以前的 Pipelined HotStuff 公式中是一個嚴重的問題,因為它開啟了破壞共識的多塊 MEV 攻擊。
緩解這個問題是一件大事,因為它為我們提供了 Pipelined HotStuff 的所有好處——頻繁的區塊、低延遲、大型驗證者集——同時避免了最大的缺點。
MonadBFT 還為最終確定性提供了巨大的升級。它具有單時隙 (500 ms) 推測性最終確定性和雙時隙 (1s) 硬確定性。
“推測性終局性”是指“僅在大多數驗證者模棱兩可(雙重簽名)的情況下才會恢復的最終性”。模棱兩可是大多數區塊鏈系統中的重大違規行為,通常會受到罰沒;模棱兩可的懲罰越大,你就越能想到 「推測性終局性 」與終局性。
單槽推測確定性是高性能應用程式的巨大解鎖,它可以在收到下一個區塊後立即自信地顯示世界的更新狀態。
這些屬性使 MonadBFT 在共識方面取得了巨大進步,並且是 Monad 中其他復合改進(包括異步執行、樂觀並行執行和 MonadDb)的有價值的補充。
本文的其餘部分總結了 HotStuff 中的連續改進是如何相互構建的,以解釋 MonadBFT 解決的問題。
總結一下:
1. HotStuff 為我們提供了線性通信的複雜性,因此我們可以擁有大型驗證器集,但效率不是很高
2. 流水線 HotStuff 為每個時隙都提出區塊,為我們提供了效率和低延遲,但存在尾叉問題
3. MonadBFT 給我們帶來了尾叉阻力和一時隙投機最終性
---
HotStuff:線性通信複雜性支援大量節點
HotStuff 演算法在幾輪通信過程中完成,通常採用「扇出、扇入」的形式,直接從領導者到驗證者再回到領導者。
每一輪開始時,領導者直接向其他驗證者發送消息,每個驗證者都發回一條簽名消息,證明已收到該消息。
如果絕對多數 (2/3) 的驗證者發回證明,則每一輪結束時,領導者將已簽名的證明匯總到仲裁證書 (QC) 中,以證明絕對多數驗證了前一條消息。
HotStuff 演算法有像這樣的多輪通信。
- 來自領導者的第一條消息是一個區塊提案
- 第二條消息是該區塊提案的 QC
- 第三條消息是關於前一個 QC 的 QC(即 QC-on-QC)
- 依此類推
如果該過程在 finality 之前的任何時間中斷,則該塊將無法完成並被丟棄;來自該區塊的交易必須重新包含在下一個區塊中。
最初的 HotStuff 協定沒有流水線,在最終確定之前有 3 輪通信;同一驗證者在每一輪中扮演領導者的角色。
---
流水線 HotStuff:每個 slot 都有一個新區塊,效率更高
流水線是我們所有人在有兩堆衣服要完成時憑直覺做的事情。在流水線中,我們不是等待負載 1 完成整個迴圈后再開始負載 2,而是在負載 2 進入洗衣機的同時將負載 1 放入烘乾機。
您可以將原始的 HotStuff 視為那種天真的洗衣方法(在載入 1 完全完成之前不要從負載 2 開始),而 Pipelined HotStuff 正在執行以交錯方式進行多個洗衣載入的直觀行為。
在 Pipelined HotStuff 中,我們將提案交錯進行,這樣每一輪都會提出一個新的區塊,新區塊搭載在攜帶前一個區塊的 QC 的消息之上。
區塊提案在多輪過程中走向最終結果。
流水線的好處是顯著的。流水線提高了區塊提案的密度,因為每個時隙中都有一個區塊提案,這提高了輸送量並縮短了最終確定的時間。
但是,流水線有一個主要缺點,最好用一個示例來說明。假設區塊 N、N+1 和 N+2 的領導者是 Alice、Bob 和 Charlie。
如果 Bob 錯過了他的位置,那麼 Alice 的提案也將無效,因為 Bob 的資訊同時包含他的提案和 Alice 提案的 QC。
當這種情況發生時,Charlie 最終被要求生成一個區塊,就好像Alice的提案從未存在過一樣。
我們將這種行為稱為 「tail-forking」,它可以被認為是深度為 1 的小型重組。
尾部分叉的可能性會產生重大後果,因為錯過 slot 不一定是偶然的。
如果有機會通過重新挖掘 Alice 的區塊來提取價值,同時重新排序或省略一些交易,那麼 Bob 和 Charlie 可以串通一氣,讓 Bob 故意錯過他的插槽,從而觸發 Charlie 重新挖掘 Alice 的區塊的機會。
這是 Pipelined HotStuff 協定(其中一些協定目前在主網中)的一大缺點。
---
MonadBFT 改變了這一點
MonadBFT 是第一個啟用流水線的協議,同時使演算法抗尾叉。
當 Bob 錯過了他的 slot 時,這種尾部分叉阻力來自回退程式,這使驗證者能夠將他們對 Alice 的提案及其在驗證者集中的共識水準的集體知識拼湊在一起。
特別是,在 MonadBFT 下,如果 Bob 錯過了他的 slot,那麼回退程式會讓驗證者通過簽名證明相互通信,說明他們是否看到了 Alice 的區塊。
如果絕對多數證明 Alice 的區塊,那麼 Charlie 將被迫重新提出 Alice 的區塊。如果 Charlie 希望提出一個不同的區塊,那麼他必須提供大多數驗證者的簽名證明,證明沒有按時看到 Alice 的區塊。
在典型的情況下,Charlie 重新提議 Alice 的區塊,然後他可以在下一輪中提出他的區塊。
結果是兩個重要的屬性:反尾叉和投機性單時隙最終性。我們已經討論了 tail-forking resistance,但讓我們瞭解一下對 finality 的影響。
和以前一樣,假設區塊 N、N+1 和 N+2 的領導者是 Alice、Bob 和 Charlie。
在 Pipelined 2-Phase HotStuff 下 - 即在 MonadBFT 之前 - 作為驗證者(或全節點),在看到 Charlie 的區塊提案之前,您無法最終確定 Alice 的區塊提案。為什麼?因為如果你在看到 Bob 的提案後立即敲定,那麼 Bob 可能只是將他的提案轉發給你,從而惹你生氣,他實際上打算不將他的提案發送給其他人,從而錯過了他的位置。
但是在 MonadBFT 中,只要你看到 Bob 的提案,你就可以“推測性地”最終確定 Alice 的提案,因為 Bob 的提案包括對 Alice 提案的 QC,這證明 2/3 的網络證明瞭 Alice 的提案。
即使 Bob 只將他的提案轉發給您,並且最終會錯過他的插槽,您也知道網路中的絕大多數人都看到了 Alice 的提案,並且當他們參與回退程式時,將再次簽署 Alice 的提案。
Alice 的區塊無法最終確定的唯一方式是驗證者模棱兩可並簽字表示他們沒有看到 Alice 的消息。這個錯誤很容易證明 - 我們已經簽署了來自他們的衝突消息。如果模棱兩可的懲罰是巨大的——而且應該是——那麼這種“推測性”的最終結果實際上並不是真正的推測性。
---
要點
MonadBFT 是一個非常令人興奮的共識發展,是 Monad 中其他複合改進的有價值的補充,包括異步執行、樂觀並行執行和 MonadDb。
衷心祝賀 @MohammadMJalal1 和 @KushalBabel 取得這一重大突破。
MonadBFT 將很快在 Monad 測試網上實現,該測試網目前實現了流水線 2 階段 HotStuff。
如需進一步閱讀,請參閱下一條推文中連結的博客文章和論文。


26.24K
熱門
排行
收藏