Solana 將於 10 月 21 日啟動 Alpenglow 升級,目標實現 150 毫秒最終確認

SOL
主網啟用Alpenglow 升級共識升級驗證者最終性SolanaVotor
1 小時前來源: crypto.news
Solana 將於 10 月 21 日啟動 Alpenglow 升級,目標實現 150 毫秒最終確認

Solana 的開發者已將 Alpenglow 共識升級安排在 10 月 21 日,目標是實現約 150 毫秒的最終確定性,同時要求驗證者和應用程式營運者在主網交接期間為變更做好準備。

摘要

  • Solana 的 Alpenglow 升級預定於 10 月 21 日進行,目標是實現約 150 毫秒的交易最終確定性。
  • Quicknode 警告在交接期間可能出現短暫的交易暫停以及可能的資料串流中斷。
  • 驗證者必須使用相容的軟體,並為投票帳戶存入 0.8 SOL 的准入費用。
  • 部分 RPC 節點可能會比直接參與共識的驗證者更晚收到最終確定性資訊。

Quicknode 的維護通知指出週三為計畫啟動日,但其最新更新警告,隨著區塊生產推進,原先估計的 UTC 14:50 可能會提前至 UTC 13:20。該供應商要求營運者從 UTC 13:00 起做好準備,共識交接將在啟動後約 20 分鐘進行。

Solana 基金會目前的升級頁面將此變更置於 epoch 1064,並列出主網尚未啟動。其更新後的估計將該 epoch 的開始時間置於 UTC 13:20 左右,使 epoch 邊界成為相關的觸發條件,而非固定的時鐘預約時間。

Solana Alpenglow 的目標是最終確定性,而非更快的執行

在 Anza 的設計下,Votor 取代了 TowerBFT 的投票和最終確定性邏輯。目標是在正常網路條件下約 150 毫秒,但並不保證每個錢包、交易所或交易應用程式都會在該期間內顯示已完成的交易。

基金會表示交易執行、程式行為和費用機制保持不變。普通使用者無需改變他們簽署或批准交易的方式,而獨立的 Rotor 資料分發升級則保留至後續版本。其文件將共識推出與先前對 slot 持續時間的縮減區分開來,後者決定網路產生區塊的頻率。

Quicknode 的技術概述描述了兩條同時運作的投票路徑。當 80% 的驗證者參與時,其中一條可以在單一輪次中完成區塊的最終確定,而另一條則在參與率達到 60% 時使用第二輪。

該供應商將此過程與使用者已經看到的早期確認區分開來。其概述指出,在樂觀設定下,應用程式通常會在兩到三秒內顯示確認,而舊系統則需要約 13 秒才能達到完全最終確定性。

10 月的部署遵循了早先將 Alpenglow 與 Agave 4.3 連結的路線圖。8 月 14 日的一份報告記錄了Alpenglow 程式碼已存在於 Agave 4.2 中進行測試,但並未授權在該版本中啟動主網。

截至 9 月 26 日,該升級在測試網於前一天過渡後已到達開發網,正如 crypto.news 先前所報導。應用程式團隊隨後可以在處理使用者資金的網路上部署之前,檢查新的共識行為。

交易者在交接期間面臨短暫中斷

Quicknode 警告,當網路切換共識系統時,新交易將短暫停止進入區塊。其通知描述暫停持續數秒,如果過渡需要更多時間,則可能出現更長的中斷。

該供應商表示,交易提交可能會暫時返回「節點不健康」的預檢錯誤。Yellowstone 資料串流可能會斷開一次,而使用最早處理承諾的訂閱可能會顯示從未達到確認的 slot。

維護通知建議對不可回滾的資料使用已確認或已最終確定的承諾。Quicknode 表示其現有的 Solana 端點將保持不變,其團隊將在整個變更期間監控網路。

在該供應商的技術概述中,更快的不可逆結算與金融應用程式、企業資金轉移和即時服務相關。該文件將這些用途呈現為所提議共識架構的能力,但並未確認個別交易平台會在啟動日採用新的結算政策。

驗證者準備工作包括軟體與帳戶資金

Solana 基金會目前的檢查清單指示驗證者在 epoch 1064 之前運行 Agave、Jito-Solana 或 Harmonic Salsa 的 4.3.2 版本。根據同一指引,遷移期間不支援 Firedancer 和 Frankendancer。

營運者必須在其投票帳戶中保持至少高於免租金最低餘額 0.8 SOL,以支付驗證者入場票。首次收費用於支付 epoch 1065 的參與費用,未繳費用將導致驗證者無法在下一 epoch 中投票或產生區塊。

治理批准早於這些營運要求。根據對已完成投票的報導,該提案於 2025 年 9 月通過,98.27% 的投票支持。參與率代表 52% 的質押量,因此批准百分比描述的是已投出的票數,而非全體驗證者群體。

該次較早的投票批准了 SIMD-0326,即共識全面改革背後的提案。當時的報告記錄了 1.05% 反對和 0.69% 棄權,公佈的數據中保留了微小的四捨五入差異。

RPC 交付可能落後於 150ms 目標

Anza 的營運者文件解釋,共識訊息通常在已准入的驗證者之間流通。使用預設交付路徑的未質押節點從後續區塊中攜帶的憑證獲知最終性,通常會增加最多一個已產生區塊的間隔時間。

跳過或延遲的區塊可能延長該等待時間。與已准入驗證者合作的節點可以直接接收訊息,儘管兩者之間的網路延遲仍是交付時間的一部分。

九月的 devnet 報導記錄了索引器和區塊瀏覽器的分別變更。候選區塊在確認之前必須保持分離,驗證者參與數據從普通的投票交易轉向附加於區塊數據的憑證。

根據該報告,移除投票交易會改變儀表板總計,即使用戶支付和交易的數量保持不變。同時計算這兩個類別的服務必須重置其比較,而追蹤驗證者投票的系統則需要讀取替代的憑證數據。