Solana（SOL）更新驗證者與開發工具，涵蓋Alpenglow轉換前後

Solana基金會（Solana Foundation）在Alpenglow共識轉換前後，發布驗證者軟體與開發工具的新版本，內容也涉及驗證者運作條件和區塊資料處理方式。

基金會在10月22日的開發者變更紀錄中，列出Agave v4.3.2、Firedancer主網版v26.10.4、Web3.js v3.1.1，以及多項JavaScript SDK更新。更新項目包括地址查找表，以及供質押、系統和代幣程式使用的SDK。SDK是用於開發應用程式和程式的工具組。

各版本的發布日期不同：Agave v4.3.2於10月15日發布，Web3.js v3.1.1於10月19日發布，Firedancer v26.10.4則於10月21日發布。Agave和Web3.js在Alpenglow啟用前推出；Firedancer則在啟用當天發布，因此僅憑發布日期無法判定先後。

Solana（SOL）主網在Epoch 1064啟用Alpenglow，時間為10月21日晚上9時36分（台灣時間）。這項轉換改變了驗證者對交易排序與最終狀態達成共識的方式。

Solana基金會的轉換說明指出，系統先維持既有的TowerBFT約5,000個slot，之後從第459,653,000個slot起採用新共識。基金會在10月21日的轉換說明中表示，目標是將最終確認時間從原本約12.8秒縮短至約150毫秒。

150毫秒並非實測值。本刊曾報導，主網啟用初期的確認時間為6.6秒，0.15秒的目標尚未達成。

Alpenglow轉換沒有改變程式執行、交易格式或手續費制度；驗證者投票交易則從區塊中移除，交易狀態「confirmed」與「finalized」也指向相同狀態。歷史證明（Proof of History，PoH）的tick項目同樣從資料串流中移除。

統計區塊交易數或為資料串流建立索引的開發者，應重新檢查既有處理方式。若指標計算包含投票交易，轉換前後便難以依相同標準比較。這項變化是Alpenglow啟用所致，與SDK更新無關。

Firedancer v26.10.4的版本說明表示，該版本修正Agave與Firedancer的gossip表不一致所造成的流量增加和處理負擔，也調整了節點落後時使用的復原演算法。基金會的變更紀錄則記載，Firedancer已參與新共識。

不過，轉換當時的支援條件是另一回事。Solana基金會的說明指出，當時Firedancer與Frankendancer尚未支援遷移，因此驗證者必須使用以Agave為基礎的客戶端。後續版本發布或參與新共識的紀錄，不代表這些客戶端在轉換當時已投入使用。

驗證者的投票帳戶必須持有高於最低豁免餘額0.8 SOL的資金。基金會表示，這筆餘額用於驗證者參與費用「Validator Admission Ticket」；未達條件者，將無法在下一個Epoch參與投票和產生區塊。

Agave變更紀錄也列出尚在進行中的改善，包括調整緩衝區以減少檔案系統輸入輸出中的頁面錯誤、依質押規模處理gossip訊息，以及降低快照載入對帳戶質押清單的依賴。團隊也正準備在上傳前，以CLI檢查排除不支援的sBPF程式版本。

Web3.js v3.1.1是既有v3版本的後續更新。本刊10月6日曾報導，Web3.js v3推出後，既有應用程式需要修改非同步程式碼。

Web3.js變更紀錄也提到一項討論：若另有SIMD提案限制舊版與V0交易格式，是否只支援Transaction V1。這仍屬於以該提案為前提的評估，並不代表舊交易格式已完成淘汰。