根據 Metrika 對該事件的分析，在 8 月 12 日的事件中，約 90 個持有約 29% 質押 SOL 的 Solana 驗證者失去連線，區塊最終確認耗時最長約 30 分鐘，而平常僅需 13 秒。

然而 Solana 從未宕機。區塊持續產出，當天的上線時間圖表本會顯示平常的一天。10 月 21 日（週三），網路預定啟用 Alpenglow，這項升級以約 150 毫秒的最終確認為目標——但其中沒有任何內容觸及引發這次驚險危機的託管問題。Fidelity 旗下 FCAT 單位於 10 月 16 日發布的研究報告 The State of Solana: Network Health and Resilience 指出，最大託管網路持有約 29% 的質押份額，接近 Metrika 觀察到的離線比例。

8 月 12 日發生了什麼

只有在超過三分之二的質押 SOL 正在投票時，Solana 才能最終確認區塊——即交易不再可逆的時點——這個過程通常需要約 13 秒。8 月 12 日，在約 71% 的質押仍在線的情況下，網路勉強保持在這條線之上。Metrika 統計的離線比例為 28.83%，而全鏈最終確認停止的門檻為 33.34%。

圖表：8 月 12 日質押 SOL 的離線比例，與最終確認停擺線的對照。資料來源：Metrika。

據 Metrika 表示，受影響路由上若再有四到五個百分點的質押，就會造成需要協調復原的全網停擺。故障始於 TeraSwitch 位於邁阿密的設施，並蔓延至倫敦、阿姆斯特丹、法蘭克福、新加坡和東京的驗證者基礎設施，且在大多數情況下，受影響驗證者的備援系統從未啟動。

TeraSwitch 在診斷出故障後約十分鐘完成修復，流量於 04:16 UTC（故障開始後 33 分鐘）恢復。驗證者在隨後 40 分鐘內陸續復原。在這段期間，未產出區塊的排定時段比例從低於 1% 跳升至 32% 以上。非投票交易每秒從約 1,100–1,300 筆降至低於 300 筆。約半小時內完全沒有區塊完成最終確認，隨後積壓一次性清空，從產出到最終確認平均耗時 1,600 秒。

唯一沒有變動的數字是上線時間，它維持在 100%，因為鏈從未停止產出區塊。但在約半小時內，沒有人能說出一筆付款何時會變得不可逆。Metrika 是一家銷售數位資產風險管理平台的公司，本次分析亦採用其自身指標，它將最終確認延遲——而非宕機——視為對任何在 Solana 上結算資金者真正重要的事件。

鏈條停擺意味著什麼、不意味著什麼

FCAT 所描述的風險是最終確認停滯和可能的審查。報告指出，持有超過三分之一質押的聯盟可以阻止其餘部分達到最終確認所需的三分之二，但不會獲得對用戶資產的無限制控制權，也無法改寫已最終確認的交易。一次奪走相同質押份額的託管故障，無需任何人發動攻擊，就會使最終確認停擺。

這個份額並不難達到。FCAT 統計約有 20 個驗證者身分（另一處為 18 個）持有超過三分之一的質押，並指出這三分之一分布在兩個國家、兩個託管網路和兩種基礎客戶端實作上。這些是投票帳戶，而非獨立組織：例如 Figment 就營運該組前五大驗證者中的兩個。FCAT 的整體評價是正面的，援引超過兩年未發生重大主網中斷、2026 年投票成功率平均約 99.7%，以及正在緩慢多元化的軟體堆疊。它將集中度列為需要持續關注的事項。FCAT 是 Fidelity 的應用技術研究單位，本身也營運一個小型 Solana 驗證者。

兩個月後，該比例仍約為 29%

FCAT 的 10 月快照顯示，最大託管網路持有約 29% 的質押。這兩個數字衡量的是不同的事物——故障期間的離線質押與一個網路佔全部質押的份額——但結果落在同一個地方。FCAT 表示，Solana 基金會早已著手削弱 TeraSwitch 的主導地位。以下是這些數字的拆解，從營運驗證者的業者到他們執行的程式碼：

• 18–20 個營運者——持有超過三分之一質押的驗證者身分。這些是投票帳戶，而非獨立組織；Figment 營運該組前五名中的兩個。
• 約 40% 地理位置——位於法蘭克福和阿姆斯特丹的質押份額。這是一項 FCAT 稱可能不準確的 IP 地理位置估計；約 59% 位於德國、荷蘭和美國。
• 約 29% 網路供應商——根據 10 月快照，位於單一託管網路上的質押份額。不同城市的驗證者可能共用同一供應商，同一城市的驗證者也可能使用不同供應商。
• 約 63% 軟體——第三季使用 Jito 系軟體的質押份額，另有 26% 使用 Harmonic。大多數配置底層仍共用 Agave 程式碼，因此一個錯誤可能同時影響它們。

資料來源：FCAT，The State of Solana: Network Health and Resilience（2026 年 10 月）。

驗證者聚集是有原因的。FCAT 指出，低延遲促使節點彼此靠近，而 TeraSwitch 和 Latitude 等專業主機商會為 Solana 的工作負載打造硬體。營運者確實有保護措施：故障轉移、備用電源，以及降低對公共網路依賴的 DoubleZero 等私人網路。基金會也在 2026 年初建立了事件回應網路 SIRN。不過在 8 月 12 日，大多數備援系統從未啟動。

基金會的限制僅觸及約 4% 的質押

Solana 基金會的委託計畫設定了主要規則。自 2026 年 5 月 1 日起，想要獲得基金會質押的驗證者，必須位於份額低於 25% 上限的託管網路以及低於 15% 的資料中心。未達標的驗證者將失去基金會託，直到再次通過為止。

這些限制在 8 月故障發生前三個月生效，而根據 FCAT 的 10 月快照，最大網路仍高於上限。該計畫的覆蓋範圍是問題的另一半。截至第三季，它向約 51% 的驗證者委託，但這些委託僅佔活躍質押約 4%。這項規則給了驗證者多元化的理由，但無法約束其餘的質押。

FCAT 的 10 月數據顯示最大託管網路佔約 29% 的質押——高於基金會的 25% 上限——而截至第三季，基金會的計畫僅委託了約 4% 的活躍質押。

Alpenglow 修復了什麼、沒修復什麼

Alpenglow 將在 epoch 1064 於主網上線，Solana 表示該 epoch 於 10 月 21 日（週三）約 15:00 UTC 開始；Agave 客戶端背後的團隊 Anza 則表示約 14:50。舊投票系統在前 5,000 個時段（約 18 分鐘）內繼續運行，新系統於時段 459,653,000 接手。最終確認時間預計從約 12.8 秒降至約 150 毫秒，Solana 稱這是預期值而非固定值。錢包和應用程式的運作方式與現今相同。

這項升級對託管問題毫無幫助。更快的投票縮短了達成共識所需的時間，但 Solana 的升級頁面上沒有任何內容改變驗證者的執行位置或連接他們的供應商。

目前它也縮窄了軟體多元化。驗證者必須在基於 Agave 4.3.0 的版本上執行 Agave、Jito-Solana 或 Harmonic Salsa。Firedancer 和 Frankendancer 在遷移期間不受支援，且 Solana 的頁面未給出支援恢復的日期。Firedancer 是獨立的程式碼庫，FCAT 稱之為 Solana 邁向獨立客戶端多元化最重要的一步。驗證者還必須在投票帳戶中持有高於免租金最低額至少 0.8 SOL，否則將無法在下一個 epoch 投票或產出區塊。

• 啟用前——現在至 10 月 21 日約 14:50–15:00 UTC： Firedancer 和 Frankendancer 營運者遷移至基於 Agave 的客戶端，且每個投票驗證者的投票帳戶須持有高於免租金最低額的 0.8 SOL。
• 切換時——epoch 1064 開始： 舊投票系統在前 5,000 個時段（約 18 分鐘）內運行，Alpenglow 於時段 459,653,000 接手。
• 啟用後——資料面的變化： 投票交易離開區塊，因此交易計數下降；confirmed 與 finalized 成為同一狀態；參與資料移至區塊尾端憑證。

監測方式也在改變。Metrika 的分析將每個區塊的投票數視為衡量網路距離最終確認線多近的最接近指標，因為投票是承載在區塊中的普通交易。Alpenglow 將投票移出區塊，Solana 的遷移說明指出，任何透過解析投票交易來衡量驗證者參與度的工具都需要新的資料來源，因為這些資料移入區塊尾端的憑證中。回報的交易計數也會下降，但實際活動並未減少。

本週應檢查什麼

如果你質押 SOL： 在委託之前查詢你的驗證者託管在哪裡。FCAT 和基金會都使用的資料來源 Validators.app 會按託管網路和資料中心追蹤質押。位於最大網路上的驗證者同樣承擔 8 月的風險。

如果你在 Solana 上開發： 預期週三交易計數和 TPS 儀表板會下降，而實際活動沒有變化。在 Alpenglow 上線前繼續以 confirmed 為準，之後依照 Solana 遷移說建議改用 finalized。在啟用之前，finalized 仍意味著約 12.8 秒的等待。重新檢查任何針對該延遲調校的超時或重試邏輯，並將最終確認時間與上線時間一併追蹤。

如果你營運驗證者： 如果你使用 Firedancer 或 Frankendancer，請在 epoch 1064 之前切換至基於 Agave 的客戶端，並確認投票帳戶持有 0.8 SOL。

週三之後，有兩個數字值得關注：最大託管網路的份額是否降至基金會 25% 上限以下，以及 Firedancer 何時重新獲得支援。這兩項都不在週三的行程上。

本文僅供參考，不構成財務或投資建議。