TLDR

• 2026年9月18日，Solana的目標出塊時間降至250毫秒，對應區塊高度（epoch）1037。

• 來自爲期60分鐘樣本的早期數據表明，出塊落點約爲266毫秒，跳過率爲0.05%。

• 一份草案提案將隨着網絡可能邁向200毫秒的出塊時間，削減每個出塊的計算限制。

• 在擬議的200毫秒設置下，領導者交接窗口將從1秒縮短至800毫秒。

• 8月在託管服務商TeraSwitch發生的路由故障，使約33分鐘內有28.83%的網絡質押無法被訪問。

Solana的網絡現在運行的目標槽位時間爲250毫秒。槽位是驗證者獲得生成區塊的時間窗口，因此更短的間隔爲用戶提供了更頻繁的事務落地機會。

根據Solana工程變更日誌，該變更於2026年9月18日在epoch 1037生效。Solana Compass在當天大約05:06 UTC完成了精確的過渡。

9月20日抽樣覆蓋了60個一分鐘窗口。結果顯示，槽位平均約在266毫秒處落地。epoch 1037跳過了約0.05%計劃中的槽位。

更緊的計算預算

一份名爲SIMD-0525的草案設計將把步進進一步推進到200毫秒。該提案也降低了每槽位的計算預算。

在250ms時，預算爲62.5百萬計算單元；在200ms時，將降至50百萬。無論哪種情況下，網絡整體的上限仍接近每秒250百萬計算單元。

這意味着區塊會更頻繁地到達，但每個區塊所允許承載的工作量會更少。實際的交易吞吐量仍取決於需求，以及領導者如何填充可用的區塊空間。

交接、地理位置與基礎設施

在新的設計下，四槽位的領導者窗口保持固定。這意味着每個領導者在250ms時有一秒，在200ms時有800毫秒，用於接收流量並生成區塊。

地理位置會影響該窗口。Solana基金會的分析發現，當連續領導者之間距離小於500公里時，首個槽位延遲的中位數約爲28毫秒。

當領導者之間相距超過8,000公里時，該延遲增至約122毫秒。這個數字相當於200ms目標槽位的61%。

工程師正在測試兩種修復方案。Agave開發者正在構建轉發方法：當可能來不及發送到指定領導者時，就提前發送交易。

客戶端團隊也在測試區塊與交易執行，符合共享的約束標準。與此同時，即使在200ms的提案之下，repair-defer閾值仍保持在250ms。

8月的另一個事件展示了基礎設施集中如何影響網絡。8月12日，託管服務提供商TeraSwitch發生一次路由故障，導致12個站點失去可達性。

Solana Compass在這次事件期間，測得約33分鐘內網絡質押的28.83%處於逾期狀態。Solana基金會表示，區塊在整個期間仍持續落地。

9月7日的數據表明，Solana的Nakamoto係數爲18，最大的單一驗證者持有約4%的有效質押。TeraSwitch在當天託管了22.1%的有效質押，低於前一年據稱的38%。

客戶端軟件也高度集中。9月20日的一項查詢顯示，約87.4%的質押在運行4.x客戶端版本；0.x和26.x版本佔比較小。

截至2026年9月20日，200ms這一特性尚無確認的激活日期。Solana官方文檔表示，進一步縮短槽位時間取決於持續的網絡性能表現。

另一個名爲Alpenglow的升級，目標是在不同時間表下實現大約150ms的交易最終性：規劃窗口從2026年第三季度到10月Agave 4.3發佈。200ms槽位時間的決策將依賴於對跳過率、領導者交接以及網絡基礎設施提供商在全網範圍內的客戶端表現的持續測量。

“Solana削減槽位時間至250ms，並瞄準200ms目標”一文最早發佈於Blockonomi。