錯過 Agave 4.4.1 升級的 Solana 驗證者會怎樣？

Anza 要求 Solana 節點營運者在 epoch 1079 之前安裝一個補丁，該補丁改變了網路計算交易載入之帳戶資料的方式。執行舊版本的機器可能仍保持線上，卻仍與被接受的鏈脫節，這對賺取質押獎勵的驗證者以及錢包依賴其提供最新資料的服務而言，會有不同的後果。

Anza 在 epoch 1079 之前警告驗證者，執行舊軟體的營運者在網路啟用新規則時，有被拋在後頭的風險。所引用的相容版本為 Agave 4.4.1 與 Firedancer v26.10.6。

Agave 功能閘門追蹤器將相關變更識別為 loader-v3 ProgramData 帳戶的最小已載入資料大小。其版本下限表將測試網路所使用的發布版本與計畫用於主網的版本分開列出。閱讀時程需要同時檢查叢集、功能與 epoch。

該截止期限也涵蓋不投票的節點。這些機器可以為錢包與交易所提供餘額、區塊雜湊與確認資料。其中一台出現問題，就可能波及從未委託 SOL 或選擇驗證者的使用者。

此變更的作用

Solana 程式可以使用帳戶來存放其可執行資料。當一筆交易需要載入程式時，網路會計算與該操作相關的資料。套用於程式資料帳戶的最小值，會改變相容軟體在新規則下處理相關交易的方式。

功能閘門的目的是協調參與者何時開始使用新規則。營運者可以提前安裝發布版本，而實際的規則變更則在約定的時間點生效。因此，某個版本可以在該功能於主網啟用之前就支援它。

一旦閘門啟用，舊版本可能會在交易或區塊所產生的狀態上，與已升級的軟體產生分歧。驗證者接著可能停止跟隨網路其餘部分所認可的鏈，即使伺服器本身仍保持線上。這就是 Anza 關於被分叉出去的警告的實際含義。

節點背後的質押為何重要

一百個小型驗證者與少數大型營運者未必代表相當數量的投票質押。就網路的運作而言，相關問題是有多少質押遵循相容規則。追蹤器指出，主網次要版本下限的變更通常遵循質押採用門檻與等待期。該一般規則應與 epoch 1079 之前所發出的具體警告區分開來。

採用檢查應將版本資訊與活躍質押配對，然後將這些數字與邊界之後的投票參與情況相比較。回報正確版本的節點可能仍在追趕，或正經歷另一項故障。反之，穩定的總體數據可能掩蓋較小營運者的問題，只要大部分質押仍保持線上並正常投票。

這種差異對委託者很重要。他們的體驗取決於其質押被指派到的驗證者，而非取決於多數機器是否安裝了該發布版本。如果驗證者停止有效投票，錯過的參與可能減少歸屬於該質押的獎勵。相關證據將是受影響 epoch 的投票信用與獎勵記錄。

使用者與交易所會注意到什麼

發送 SOL 的使用者關心的是轉帳是否被接受，以及是否達到預期的確認層級。這可以透過交易與網路資料來查核。聲稱數個營運商錯過了一次更新，本身並不能證明確認變慢、網路停止或大規模中斷。

交易所在監控升級期間也可能暫停存款或提款，即使鏈上轉帳仍在持續進行。其客戶餘額取決於交易所自身的基礎設施與入帳政策。因此，一筆已在鏈上出現的交易，可能仍會在客戶的交易所帳戶中處於待處理狀態，直到該平台恢復正常處理為止。

有用的升級後比較會分別檢查三件事。第一，區塊是否持續被產生與確認？第二，質押投票的數量是否實際發生變化？第三，是否有任何具名交易所在邊界前後暫停或恢復轉帳？每個問題都需要不同的紀錄。

為何升級期限也適用於基礎設施

Anza 的 Agave 發行說明 將 ProgramData 會計變更標示為回溯移植。 Firedancer 發行版 則包含對同一功能的支援。當兩個用戶端在啟用後處理同一筆交易時，它們必須對該交易載入多少帳戶資料達成一致。在邊界時刻，共享的規則才是關鍵。

未質押的 RPC 節點可以為應用程式提供服務，而不對投票貢獻質押。這使得錢包使用者即使投票驗證者持續產生區塊，也很容易遇到本地問題。從落後端點讀取的應用程式可能顯示舊狀態或傳回錯誤。將其回應與透過另一個端點發出的相同請求進行比較，有助於找出中斷發生的位置。

Solana 的 十月 Alpenglow 遷移 提供了營運商如何為協調式變更做準備的背景。該次遷移涉及共識協定。十一月的修補程式則涉及帳戶載入。兩者都給營運商一個可供驗證的版本，但必須對照實際變更的特定規則來評估其影響。

是什麼讓期限不同於發行日期

Anza 於 11 月 5 日發布 Agave 4.4.1。其隨後 對營運商的警告 表示，該變更計畫於 epoch 1079 進行，估計於 11 月 6 日約 13:30 UTC 開始。版本標明了營運商所需的軟體，而 epoch 則標明了網路計畫開始套用該規則的時間。

epoch 邊界取決於鏈的進展。警告中的時間為營運商提供了實際估計，但鏈過渡到新 epoch 才是重要事件。營運商不能將較晚的當地時間或例行維護時段視為時程的延長。

一個發行版可能包含尚未改變網路處理交易方式的程式碼。營運商先安裝軟體，然後網路在計畫時點啟用該功能。這樣的順序讓營運商得以做好準備，而不會讓節點立即對同一區塊套用不同規則。

即使對於已經轉移到 Agave 4.4.0 的營運商而言，這個時間窗口也很短。修補程式編號只變動了一位，但較早的發行版缺乏新規則所需的支援。因此，最近才安裝並不能取代對確切建置版本的檢查。

Firedancer 26.10.6 發行版 支援同一功能。營運商可以使用不同的用戶端實作，但在依現行規則執行交易時，兩者都需要計入相同的帳戶資料。

軟體與啟用之間的區別已經出現在 crypto.news 對 Alpenglow 測試網推出 的報導中。Alpenglow 改變了共識，而十一月的修補程式則涉及交易處理。在兩種情況下，建置版本可供使用與網路要求其行為，是兩個不同的里程碑。

ProgramData 在交易中的介入位置

一筆交易會列出其指令所需的帳戶。驗證者會載入與這些帳戶相關聯的資料，以執行這些指令。網路限制了單筆交易可載入的帳戶資料量，從而為驗證者在執行前或執行期間所執行的一類工作設定了上限。

Solana 的可升級載入器使用一個程式帳戶和一個獨立的 ProgramData 帳戶。後者儲存可執行程式資料以及載入器的相關資訊。使用者呼叫該程式時，無需手動計算該可執行程式資料的大小。驗證者的執行環境會處理這一部分。

該修補程式為載入時歸屬於 loader-v3 ProgramData 帳戶的金額設定了一個下限。如果舊的計算方式所歸屬的金額低於該下限，新規則就會至少按最低值計入交易的已載入資料限制。遠低於該限制的交易在變更後會產生相同的結果。

差異在邊界處才會顯現。一筆結合了多個指令或使用多個程式的交易可能已經載入了大量帳戶資料。如果新的最低值使合計金額超過限制，那麼即使指令相同、簽署者相同，舊規則與新規則也可能產生不同的結果。

已載入資料限制與運算預算不同。運算衡量的是執行工作。一筆交易可以擁有足夠的運算來執行指令，卻仍然無法通過一項管轄其可載入哪些帳戶的限制。僅提高運算額度並不會改變計入已載入資料限制的金額。

該規則也不會改動應用程式已部署的指令。程式可以位於相同位址、擁有相同程式碼，而驗證者對其 ProgramData 帳戶的計費方式卻不同。應用程式團隊有理由重新檢查接近限制的交易，即使他們自己並未進行任何部署。

兩個節點如何對同一個區塊產生分歧

驗證者執行交易以檢查區塊所產生的狀態。如果兩個節點從相同狀態出發，並對其中一筆交易套用不同的規則，它們就可能得出不同的結果。除非差異得到解決，否則它們無法同時將相同的結果狀態視為有效。

這就解釋了 Anza 關於較舊節點會脫節的警告。一個舊節點可以保持線上並繼續回應請求，卻無法追蹤相容驗證者所接受的鏈。其行程處於運行狀態，是一個比它是否為最新且與叢集一致更弱的測試。

營運者可以將節點回報的 slot 與一個獨立參照進行比對。一個投票驗證者還必須檢查其投票是否被計入所接受的鏈上。錯誤日誌可能會在重放區塊時指出問題，而這在正常運行時間檢查中是不可見的。

該警告描述了不相容的後果。截止日期之後的評估仍然需要顯示哪些營運者運行的是過時的版本，以及他們的節點發生了什麼。在營運者恢復後所收集的版本快照可能會遺漏該驗證者脫節的那段短暫時期。

啟用日期與觀察者注意到問題的時間點也可能不同。一條狹窄的規則只會影響行使該規則的交易。在邊界之後立即出現的一段沒有明顯分歧的時期，並不能顯示節點是否能夠處理接近受影響限制的交易。

為何驗證者數量只能說明部分情況

一個投票驗證者的重要性部分取決於它所代表的質押量。少數大型營運者可以代表比許多較小營運者更多的投票權重。因此，受影響機器的數量所回答的問題，與繼續參與的活躍質押百分比所回答的問題不同。

未質押的節點有另一種角色。它們可以為應用程式、交易所和錢包提供資料，或轉發已簽署的交易。一個熱門服務的中斷可能影響許多使用者，即使該服務對共識不貢獻任何質押。

相關的衡量指標可以獨立變動。區塊生產可以繼續進行，而某個特定的 RPC 提供者卻提供過時的資料。一個驗證者可以漏掉投票，而其面向公眾的網站仍保持可用。一家交易所可以暫停 Solana 存款，而鏈仍在繼續確認轉帳。

先前關於 Solana Alpenglow 截止日期的報導描述了一次需要驗證者和應用程式協調準備的交接。那裡的目標是更快的終局性。ProgramData 閘門的技術影響較為狹窄，但營運者仍然必須根據自己在網路中的位置來判斷準備情況。

委託人能從投票與獎勵記錄中確認的事項

即使網路保持可用，委託人仍有一個經濟層面的問題。他們想知道，代表他們賺取獎勵的驗證者是否持續參與。錯過一個補丁本身不會將委託的 SOL 移出質押帳戶，但投票中斷可能會減少相關期間內所賺取的獎勵。

首先應該查看的是驗證者的投票帳戶。比較邊界前後各 epoch 的投票信用，可以確認其參與情況是否發生變化。獎勵記錄則提供了對特定質押帳戶所受影響的獨立核查。

較低的獎勵本身並不能將升級認定為原因。佣金、驗證者先前的表現以及質押帳戶的狀態，都可能影響所記錄的金額。若有證據顯示投票在邊界處停止、並在客戶端變更後恢復，這會比單一較低獎勵提供更有力的解釋。

流動性質押代幣又增加了一層。一個資金池可以將其質押分散到多個驗證者身上。某個營運商的問題可能只造成資金池獎勵變化的一部分，具體取決於其在委託中所佔的份額以及資金池的會計方式。

交易所質押則增加了一層服務關係。交易所可能營運自己的驗證者，或使用其他供應商，然後依其條款為客戶入帳。使用者需要交易所的記錄，才能將鏈上投票的變化與記入個人帳戶的獎勵聯繫起來。

過時的 RPC 端點會對錢包造成什麼影響

許多錢包透過 RPC 端點取得餘額、區塊雜湊和交易結果。落後的節點可能回報先前的餘額，或無法回傳最近的交易。即使其他節點正在正常處理網路，使用者也可能遇到這些症狀。

區塊雜湊可能在網路執行交易之前就對其產生影響。取得過時區塊雜湊的錢包，可能建構出一筆在送達健康節點時已不再有效的交易。症狀是提交失敗，但原因可能是過時的資訊，而非餘額或指令的變化。

模擬依賴於同樣的關係。執行舊規則的節點可能回報某筆交易符合已載入的資料上限，即使執行新規則的節點得出不同的結果。若狀態在模擬與納入之間發生變化，在相容節點上進行的模擬仍可能與最終執行結果不同。

在單一端點後方配置多個節點的應用程式還面臨另一種可能性。請求可能因由哪台機器接收而成功或失敗。供應商必須確認整個節點池都是最新的，才能將間歇性問題歸因於鏈本身。

比較獨立的端點有助於區分這些問題。若多個最新端點結果一致，而某個服務不同，則該差異可能僅限於該服務本身。若獨立觀察者也回報區塊生產或確認發生變化，則有更強的證據顯示存在網路問題。

十月的共識轉換有其自身的基礎設施變更。Crypto.news 報導指出，Alpenglow 移除了先前的鏈上投票交易。應用程式團隊必須區分他們所觀察到的變化，與驗證者是否能遵循新系統。十一月的帳戶載入規則再次使答案取決於觀察者的角色。

為何交易所入帳可能落後於鏈上

交易所只有在其系統識別出轉帳並套用其確認政策之後，才能為存款入帳。因此，一筆成功的鏈上交易並不決定客戶在交易所內部餘額何時發生變化。

交易所在更新基礎設施時可能會暫停存款或提款。它也可能在存款隊列等待健康節點確認的同時，繼續在鏈上接收轉帳。交易所公告和區塊瀏覽器可能都是準確的，即使一個顯示服務中斷，另一個顯示轉帳成功。

對於提款，延遲可能發生在交易所簽署或廣播交易之前。在此期間沒有鏈上記錄，幾乎無法說明一旦提交，網絡是否會接受該交易。交易所的處理狀態說明了時間線中的這一部分。

一份稱多家交易所暫停運營的報告仍需要指明哪些服務受到影響，以及每家給出的原因。常規維護通知或因其他問題導致的隊列，可能與升級落在同一時間窗口內。這種巧合是比較記錄的理由，而不是衡量網絡參與度的標準。

什麼能顯示運營商是否錯過了補丁

Anza 功能門追蹤器將最低發布底線與單個激活區分開來。crypto.news 早前關於Alpenglow 推出和主網底線的報導描述了同樣的區別。一個構建可以在某一時點滿足底線，卻缺少計劃在稍後 epoch 生效的變更。

最有用的激活後記錄會在同一窗口內比較活躍功能、軟件分佈和運營商參與情況。功能記錄標識規則何時開始適用。軟件記錄標識哪些構建正在提供服務。投票和區塊顯示網絡和單個運營商的行為是否有所不同。

跳過的 slot 是一種可能的觀察。它們也可能因與補丁無關的原因而增加，包括被分配領導權的驗證者的正常表現。比較多個窗口並將跳過情況與其領導者匹配，可以為觀察提供背景。

違規質押提供了不同的視角。當一個大型驗證者停止參與時，該數量可能發生變化，即使違規節點的總數幾乎不變。比較需要考慮在升級前已經違規的運營商。

RPC 和交易所的影響必須單獨記錄。這些提供商可以服務大量用戶而不出現在質押比較中。它們的公告、服務指標以及節點何時恢復到當前 slot 的記錄，將描述投票數據無法捕捉的中斷。

為什麼分階段推出仍需要激活測試

穩定的客戶端版本可以在新功能激活前逐步部署。這讓運營商看到軟件是否正確啟動、趕上並在當前規則下處理交易。它還有助於在更多節點使用之前揭示部署問題。

激活前成功的推出無法檢驗活躍功能的每一個後果。接近已加載帳戶數據限制的交易需要在兩套規則下測試，以準確顯示結果在哪裡發生變化。這與觀察二進制文件是否保持在線是不同的測試。

Crypto.news 此前報導，Alpenglow 針對最終性採用了不同的方法。其成功標準包括確認速度的變化。ProgramData 補丁更好的評判標準是客戶端是否對遇到新限制的交易達成一致，以及基礎設施在門開啟後是否保持可用。

回滾在激活時也會改變含義。在邊界之前，較舊的受支持版本仍可能處理已生效的規則。在邊界之後，返回到缺少該功能的構建可能帶回運營商試圖解決的完全相同的兼容性問題。回退必須保留對活躍門的支持。

有備用容量的運營商可以啟動一個已打補丁的節點並在分配流量之前對其進行驗證。較小的運營商可能不得不重啟其唯一的節點並等待其趕上。截止時間是共享的，但用戶等待的時間可能取決於提供商的冗餘。

為什麼 SOL 的價格無法衡量升級的影響

SOL 可能在運營商安裝補丁的同一時段內下跌或上漲。它與其他加密資產一樣，與許多相同的貨幣和資金池進行交易。利率、比特幣的走勢和槓桿的變化可能在同一窗口內影響價格。

技術問題若中斷轉帳或使應用程式無法使用，就可能對交易產生影響。支持此解釋的證據會包括交易場所的公告、存款或提款的變化，或與相關帳戶連結的鏈上執行資料。單憑代幣價格無法辨識該管道。

單筆交易失敗也與失去對帳戶的控制不同。錢包可能以舊資訊建構交易，或透過過時的節點提交。使用者仍可控制帳戶，而應用程式卻難以連上目前的網路。

因此，截止期限後最直接的檢驗在服務層面。投票節點應處於最新狀態並記錄投票。RPC 服務應能回應來自已接受鏈的請求。交易所應能說明其是否及何時處理了在切換前後提交的轉帳。

即使價格因無關原因波動，這些證據仍可支持評估。它也讓委託人得以評估自身驗證者的表現，而不必把全網路的版本要求視為對每位營運者結果的陳述。

營運者重新上線後會發生什麼

安裝修補後的軟體只是恢復節點的一步。營運者接著需要觀察該程序是否追上已接受的鏈，並在現行規則下跟隨它。伺服器可以成功重新啟動，但仍在重播區塊或回傳落後於鏈尖的資料。

投票節點也需要顯示其參與已恢復。其營運者可將目前的投票與節點恢復的時間進行比較。日後閱讀獎勵資料的委託人便能區分恢復時點與安裝修補程式的時間。

服務提供者可將已修補的節點移出輪替，直到它追上進度並通過檢查。營運者可將槽位、近期交易的結果以及模擬的結果與另一個獨立參照進行比較。若提供者在這些檢查之前就讓節點恢復流量，可能使軟體升級看似完成，而客戶仍遇到舊資料。

評估影響時，時間軸很重要。偏離後又在同一 epoch 內恢復的節點，在之後的目錄中可能看似健康。其錯過的參與對營運者或委託人仍可能有意義。公開的事件時間軸需要足夠的細節，以顯示服務何時停止、正常活動何時恢復。

應用程式團隊也可檢視僅透過特定後端失敗的交易。若透過目前節點重新提交即可解決問題，且指令沒有任何變更，先前的端點便成為可能的失敗來源。若同一筆交易在接近帳戶資料上限的目前節點上持續失敗，則交易本身可能需要重建。

此類重建可能涉及減少交易載入的資料，或在應用程式可容忍多筆交易的情況下拆分指令。拆分交易可能改變其保證，因為原本設計為一起成功或失敗的指令可能不再如此。因此，這項變更屬於應用程式自身的設計，與其帳戶載入需求並列。

對使用者的後果取決於不相容發生在哪裡。營運者可能錯過參與，RPC 可能回傳過時資訊，應用程式可能建構出不再符合要求的交易。前兩者可透過恢復相容的基礎設施來解決，而第三者則取決於交易與現行規則。

對 Solana 復原情況的檢查應將這些觀察分開。它應比較營運者的投票記錄、提供者的服務記錄，以及受影響應用程式的執行結果。如此一來，即使網路在整個過程中持續產出區塊，也能辨識出範圍狹窄的影響。

11 月的截止期限為營運者提供了具名的版本與 epoch 邊界。其影響的持久記錄將來自節點在該邊界前後的行為，以及它們在邊界之後所能提供的服務。

觀察重點

• 相容版本：Anza 的時程與版本說明可確立主網的基準及其在各客戶端中的對應版本。
• 投票參與：活躍質押與投票點數可顯示投票參與在邊界前後是否發生變化。
• 網路確認：區塊與確認紀錄可顯示網路在變更前後是否持續處理交易。
• 交易所營運：交易所公告可確立某交易所是否暫停其自身的 Solana 存款或提款。

常見問題