Celestia的Ginger升級可以帶來哪些驚喜?

robot
摘要生成中

來源:Celestia;編譯:鄧通,金色財經

Lemongrass 升級於 9 月部署到主網測試版,是 Celestia 的首次共識升級。即將推出的 Ginger 升級,即 Celestia-App V3 是第二個。

**Ginger 使效率翻倍, Celestia 的數據可用性吞吐量立即增加了 2 倍!**在 v3 中,這是通過將出塊時間從 12 秒減少到 6 秒來實現的,這也通過更快的事務單時隙最終確定時間來改善用戶體驗。

Ginger 還為社區治理奠定了基礎,將塊大小增加到每 6 秒最大 8MB,相當於 1.33 MB/s。

**Ginger 在Arabica高度 2348907 激活(預計 2024 年 11 月 5 日)。**預計將於 11 月進入 Mocha 測試網,並於 12 月進入主網 Beta。

sQj6nkmA5DqMiKp9ogb9m0FwBMffZGn9bYzzsguJ.jpeg

Celestia 即將發生變化

Ginger 升級中包含的 CIP 在 CIP-25(一種元 CIP)中指定。

Ginger 中的 CIP 包括:

  • CIP-21:引入經過驗證的簽名者的 blob 類型
  • CIP-24:版本化Gas調度程序變量
  • CIP-26:版本化超時
  • CIP-27:PFB 和非 PFB 數量的塊限制
  • CIP-28:交易大小限制

除了上述 CIP 之外,celestia-app v3 還包含一個重要的非共識更改:默認需要 BBR。

默認為黑匣子記錄器

現實生活中的 p2p 網絡必須在很長的距離上發送大量數據。這會成為問題,因為最常見的擁塞控制算法會隨著更多丟失的發生而顯著減少發送的數據包數量,換句話說,降低吞吐量。數據傳輸的時間越長,丟失的數據包就越多,帶寬利用率就會直線下降。更糟糕的是,緩衝區開始積累,即使對於小數據包也會造成大量延遲。更糟糕的是,在去中心化網絡中,節點不會等待緩衝區中的消息;它們只會繼續到下一個塊,導致這些緩衝的消息變得陳舊,並在最終發送時浪費更多的帶寬。

谷歌的研究人員發現,數據包丟失實際上並不是檢測擁塞的良好機制。相反,我們可以簡單地使用往返時間。這就是 BBR 所做的,並導致現實生活中的地理分佈式網絡的吞吐量大幅增加。

這為未來吞吐量和性能的提高打開了大門,例如 Mammoth Mini 測試網中展示的改進。 celestia-app v3 要求默認打開 BBR。

引入經過驗證的簽名者的 blob 類型

CIP-21 引入了“創作的 blob”,其中直接將簽名者的地址包含在 blob 元數據中。 Celestia 驗證器現在驗證該簽名者是否與支付 blob 的地址匹配,從而無需彙總來單獨檢索和處理 PayForBlobs 交易。這簡化了彙總的驗證過程,允許他們直接檢查 blob 的簽名者字段以確保真實性。

版本化的Gas調度程序變量

CIP-24 將 Gas 調度程序變量 GasPerBlobByte 和 TxSizeCostPerByte 設置為只能通過網絡升級進行修改,從而消除了通過鏈上治理更改它們的能力。這一變化旨在使交易成本更加穩定和可預測。它允許更簡單的離線Gas計算方法,而無需在每次交易之前查詢網絡。

版本化超時設置

CIP-26將出塊時間和相關超時設置為由應用程序版本控制,並將出塊時間從v3中的12秒減少到6秒。此更改旨在提高網絡吞吐量並減少交易最終確定時間。它還將內存池的 ttl-num-blocks 參數從 5 增加到 12,以通過更快的塊時間保持一致的事務行為。

PFB 和非 PFB 數量的塊限制

CIP-27 對每個塊的 PayForBlob (PFB) 和非 PFB 消息的數量進行了限制。該提案實施了每個塊 600 個 PFB 消息和每個塊 200 個非 PFB 消息的限制。這些限制是PrepareProposal 階段的軟限制,這意味著它們並未在共識級別嚴格執行。此更改的基本原理是通過限制每個塊中可以驗證的交易數量來防止塊處理時間過長。這些限制是根據基準確定的,目標是在推薦的驗證器配置下每個塊的處理時間約為 0.25 秒。

交易規模限制

CIP-28 在 Celestia 上將單個事務的大小限制為 2MiB(2,097,152 字節)。此限制將在交易處理的所有階段(CheckTx、PrepareProposal 和 ProcessProposal)強制執行,因此是一個打破共識的更改。其基本原理是為了防止八卦大型交易的問題,即使是 8 MiB 或更大的區塊。它還為減少區塊時間和增加區塊大小以增加未來的吞吐量敞開了大門。

查看原文
  • 讚賞
  • 留言
  • 分享
留言
暫無留言