我的知識庫

區塊鏈 · 2026-11-06

閱讀時間約 9 分鐘

Solana 開發商 Anza 要求驗證者在 11 月 6 日約 13:30 UTC(台北時間晚上 9:30)的第 1079 個 epoch 之前升級到 Agave 4.4.1,否則會被分叉出主鏈;一週前,Anza 執行長 Brennan Watt 還提出草案,主張把 Solana 散落在客戶端程式碼與各份 SIMD 提案裡的協議規則,收斂成一份唯一的權威規格。兩件事放在一起看,講的是同一個問題:多客戶端網路靠什麼確保大家對「規則」的理解一致。昨天談以太坊的後量子時程,今天換到 Solana 的客戶端相容性。

讀到的程度:升級通知與規格提案各讀到一篇二手報導全文(Crypto Briefing、CryptoSlate),沒有打開 Anza 的原始公告或 Watt 的草案本文,也沒有看到 Agave 4.4.1 的版本說明。報導把「被分叉」的原因只寫成客戶端相容性,沒說明具體是哪個變更觸發,這個空白我無法填補。這是技術整理,不構成投資建議。

📖 學

一、第 1079 個 epoch 的升級期限

Crypto Briefing 在 11 月 5 日報導,Anza 發出緊急通知,要求驗證者升級到 Agave 4.4.1,未升級者有在第 1079 個 epoch 被分叉出去的風險,預計時間是 11 月 6 日約 13:30 UTC。分叉在這裡的意思是:協議規則在某個 epoch 邊界改變,仍跑舊規則的節點會對區塊有效性做出不同判斷,於是離開多數驗證者認定的正本鏈。這種「按 epoch 啟用」的升級,和以太坊按區塊高度或時間排程分叉是同一類做法,差別在 Solana 以 epoch 為單位。

epoch 長度我沒有在報導裡看到,但可以用本站先前記錄反推:Alpenglow 在第 1064 個 epoch 於 10 月 21 日約 13:36 UTC 啟用,到 11 月 6 日約 13:30 UTC 整整 16 天、相隔 15 個 epoch,平均約 1.07 天一個。這是我自己的推算,不是官方數字。

報導還提到預測市場的參與者把這則通知視為 SOL 價格的風險因子,這是作者的詮釋,不是 Anza 的說法,我不採用。

二、一份權威規格的提案

CryptoSlate 的報導說,Watt 在 10 月 30 日提出草案:目前 Solana 對交易處理、區塊驗證與共識的規則,散在驗證者程式碼和各別 SIMD 提案裡。新做法下,討論仍走 SIMD,但正式的變更要以「修改共用協議規格」的形式提交,審查通過後才能在主網啟用。

動機是多客戶端。Solana 現在除了 Agave,還有 Jump Crypto 開發的 Firedancer。若規則只存在於某個客戶端的程式碼,另一個團隊只能讀對方的程式碼或重建過去的升級決定來推敲預期行為。獨立實作對同一筆交易給出不同結果,就會產生對鏈狀態的分歧,威脅網路可靠性。規格文件能在驗證者意見不一時,提供判斷哪個實作該修正的標準。

三、草案的範圍與限制

草案涵蓋 18 個領域,包括交易處理、網路、共識、手續費與驗證者獎勵。它以主網第 1072 個 epoch 為參考點:實作從一個認證到該 epoch 根的快照或狀態起跑,不必重放已退役的舊規則。它只適用於該 epoch 內的 bank,沒有定義下一個 epoch 的第一個 bank。報導明確說這仍是草案,沒有建立起始狀態正確性、歷史重放或延續到下一個 epoch 的運作,也沒有量化對客戶端可靠性的改善。

四、兩件事的關聯

升級期限是「規則改了,舊客戶端被甩下」的現場版本;規格提案是「怎麼讓規則改動可被多個實作同時看懂」的制度版本。報導沒有把兩者連成因果,我也不主張第 1079 個 epoch 的升級與這份草案有關,只是這兩則新聞同週出現,剛好對照出同一類風險。

🧠 記

  • 期限: Anza 要求升級到 Agave 4.4.1,第 1079 個 epoch,11 月 6 日約 13:30 UTC(台北時間 21:30)。
  • 後果: 未升級者可能被分叉出主鏈(原因僅知是客戶端相容性)。
  • 提案: 10 月 30 日 Watt 提出唯一權威協議規格草案,18 個領域,參考 epoch 為 1072。
  • 現況: 草案不是已採納的變更,範圍到單一 epoch 內為止。
  • 邊界: 只讀到二手報導全文,沒讀 Anza 公告或草案本文。

✍️ 實踐

全部唯讀,約 40 分鐘。

  1. 找原始公告(約 15 分鐘):到 Anza 的 GitHub 或官方頻道找 Agave 4.4.1 的版本說明,確認「被分叉」的具體觸發變更,與報導對照。
  2. 讀 SIMD 流程(約 15 分鐘):找 Solana 的 SIMD 儲存庫,看一份已啟用的提案如何寫「啟用條件」,想像它改成「修改規格」要多哪些步驟。
  3. 寫比較表(約 10 分鐘):三欄分別是以太坊(分叉排程與共識規格)、Solana 現況、Watt 草案,列出「規則存放處」「變更怎麼審查」「出歧異時誰仲裁」,不確定的格子標問號。

可證偽預測(台北時間):

  • 預測一: 2026 年 11 月 13 日前,有至少一份來源報導第 1079 個 epoch 順利通過、主網沒有停擺 90%。
  • 預測二: 2026 年 12 月 31 日前,Solana 官方 GitHub 上出現把 Watt 草案列為正式流程的合併提交 15%。
  • 預測三: 2026 年 11 月 20 日前,Anza 或第三方公開 Agave 4.4.1 升級的事後統計(升級比例或被分叉節點數)30%。

🔗 延伸學習

💬 問 AI

我在整理 Solana 的兩則新聞,資料只來自 Crypto Briefing 與 CryptoSlate 的二手報導,我沒讀 Anza 原始公告或草案:
 
1. Anza 要求驗證者升級到 Agave 4.4.1,否則可能在第 1079 個 epoch(2026 年 11 月 6 日約 13:30 UTC)被分叉出主鏈。
2. Anza 執行長 Brennan Watt 在 10 月 30 日提出單一權威協議規格草案,18 個領域,參考 epoch 為 1072,仍是草案。
 
請幫我:
(a) 用白話解釋為何多客戶端網路(Agave、Firedancer)需要規則規格,以及「按 epoch 啟用升級」時舊客戶端會發生什麼事;
(b) 比較以太坊的共識規格加分叉排程做法與 Solana 目前的 SIMD 加客戶端程式碼做法,各自優缺點;
(c) 列出我該去原始來源核對的項目;
(d) 每個結論標示「來源明說的」、「你另外查到的(附網址)」、「你的推論」,不要編造連結、日期或數字,不確定就說不確定。
這是學習用整理,請不要給投資建議。

反向連結