我的知識庫

區塊鏈 · 2026-07-16

閱讀時間約 9 分鐘

Solana 正在進行上線以來最大的一次共識機制換血。代號 Alpenglow 的升級把交易最終確認時間從原本的 12.8 秒左右，壓縮到 100～150 毫秒，等於快了將近一百倍。這不是行銷話術，而是把整套 TowerBFT 投票機制連根拔起，換上全新設計的 Votor 與 Rotor 兩個子協定。測試網從 5 月中上線至今已經穩定運作兩個多月，驗證者投票（SIMD-0236）以超過九成八的支持率通過，主網切換（社群暱稱「Alpenswitch」）最快可能落在今年第三季，也就是 9 到 10 月之間。

📖 學（核心）

從 TowerBFT 到 Votor：共識為什麼要重練

Solana 原本的共識設計 TowerBFT，本質上是把驗證者的投票也當成一筆一筆的鏈上交易在處理，需要經過多達 32 輪的投票才能達到最終確認。這套機制在網路規模還小的時候堪用，但隨著驗證者數量增加、跨地域延遲拉大，投票本身反而變成拖慢區塊鏈的瓶頸——每一票都要佔區塊空間、每一票都要等網路傳播。

Votor 的做法是把整個投票流程搬到鏈下，用驗證者之間的直接訊息傳遞加上簽章聚合（signature aggregation）來達成共識，完全不佔用區塊容量。設計上分成兩種情境：當有 80% 以上的質押權益（stake）在線並參與投票時，一輪就能完成最終確認，大約 100 毫秒；如果只有 60% 左右的參與度，就退回兩輪，落在 150 毫秒上下。這種「依參與度動態調整輪數」的彈性，是它能同時兼顧速度與安全邊際的關鍵。

Rotor：把資料傳得更快，也更抗攻擊

光是投票變快還不夠，如果區塊資料本身傳播得慢，共識照樣卡住。Rotor 是用來取代舊有資料傳播機制 Turbine 的新設計，核心是「質押權重加權的中繼」（stake-weighted relays）搭配糾刪碼（erasure coding），並減少節點之間的傳遞跳數。白話講，就是讓質押量大、理論上更可信賴的驗證者去扛更多資料轉發的責任，同時用糾刪碼確保就算部分節點掉線或延遲，其他節點也能拼湊出完整資料，不必整包重傳。

這套設計呼應了以太坊那邊也在推的 PeerDAS（透過抽樣驗證大量資料，不必每個節點都下載全部內容）思路——不同公鏈在同一個時期，不約而同地把「資料可用性與傳播效率」當成擴容的下一個主戰場，而不是單純堆疊交易處理速度（TPS）這個舊指標。

Alpenswitch：主網遷移不是flip一個開關

從測試網走到主網，中間最麻煩的不是技術本身，而是「怎麼在不停機、不分叉的情況下，讓數千個驗證者同步從舊共識切換到新共識」。目前測試網已經有數十個對外開放、屬於正式生產等級的驗證者參與測試，涵蓋全球不同地區的網路環境，目的就是提前暴露真實世界會遇到的延遲、時區、頻寬落差等問題。

如果進度順利，官方預期主網遷移最快落在 9 月底到 10 月，屆時會是一次類似「換引擎但飛機還在飛」的操作。值得留意的是，官方與社群多次強調時間表「取決於測試結果」，也就是留了緩衝——這類核心共識層的變更，寧可延後也不會為了趕日期而冒風險。

對驗證者與應用層的實際影響

最終性從秒級降到毫秒級，第一個受惠的是需要即時互動的應用場景，例如鏈上遊戲、高頻交易類的金融應用，以及任何「使用者按下按鈕後想要立刻看到確認結果」的體驗。第二個影響是驗證者的營運方式——投票不再佔用鏈上空間與 gas，理論上能降低驗證者的營運成本與網路壅塞程度，但同時也意味著中大型驗證者在 Rotor 的資料轉發架構裡承擔更多責任，質押權重與網路貢獻度的掛鉤會更明顯，這對驗證者經濟的長期分佈（是否會更集中）是接下來值得觀察的重點。

🧠 記

  • Alpenglow = Votor（投票/最終性）+ Rotor（資料傳播），分別取代 TowerBFT 與 Turbine。
  • 最終確認時間：約 12.8 秒 → 100～150 毫秒，提升近百倍。
  • 80% 質押權益在線時一輪完成（約 100ms）；60% 左右時兩輪完成（約 150ms）。
  • Votor 把投票搬到鏈下，不再佔用區塊空間與交易吞吐量。
  • Rotor 用質押權重加權中繼 + 糾刪碼傳播資料，減少節點間跳數。
  • 測試網自 2026 年 5 月 11 日上線，驗證者投票（SIMD-0236）超過九成八支持。
  • 主網切換「Alpenswitch」最快落在 2026 年第三季（9～10 月），仍以測試結果為準。

✍️ 實踐

  1. 找出手上持有 SOL 或委託質押的驗證者，確認對方是否已加入 Alpenglow 測試網，評估其技術跟進能力。
  2. 若有開發鏈上應用，先在測試網環境模擬最終性從秒級降到毫秒級後，對使用者體驗流程（例如交易確認提示）要做哪些調整。
  3. 追蹤 SIMD-0236 後續的實作進度與 Alpenswitch 時間表公告，避免主網遷移當下措手不及。
  4. 比較 Solana 的 Rotor 與以太坊 PeerDAS 兩種資料可用性設計的取捨，建立自己對「擴容路線」的判斷框架，而不是只看誰的 TPS 數字比較高。
  5. 關注遷移過程中驗證者質押分佈的變化，留意是否出現資料轉發責任集中在少數大型驗證者的趨勢。
  6. 把 Alpenglow 的進度整理成自己的觀察清單，對照過去公鏈重大共識升級（如以太坊合併）的節奏，抓出風險與機會的時間窗口。

🔗 延伸學習

💬 問 AI

我正在了解 Solana 的 Alpenglow 共識升級，特別是 Votor 和 Rotor 這兩個子協定。
請幫我用 {比喻方式} 解釋最終性從秒級降到毫秒級對 {我的使用情境} 會有什麼實際差別，
並評估如果我是 {角色：驗證者/開發者/持幣者}，在主網遷移前後應該注意哪些風險。

反向連結