租金省90%未啟用 Solana Agave 4.2目標日已過

Solana(SOL)驗證客戶端開發商Anza提出的Agave 4.2目標啟用日8月17日已經過去,但最受矚目的「租金費用降低90%」功能,以及高速時隙(slot)與大額交易規格,目前仍未在主網開啟。

根據CryptoSlate的報導,於17日引述Anza功能追蹤器與Solana基金會(Solana Foundation)官方文件指出,這項落差確實存在。Anza已於11日建議一般驗證者在主網環境使用Agave 4.2,驗證者也已陸續進行軟體升級。不過,軟體版本部署與協議功能閘門(feature gate)啟用,是兩個各自獨立的程序。

所謂功能閘門,是指新協議規則不會一次套用到整個網路,而是在預先設定的條件達成後才分階段開啟。也就是說,驗證者即便完成軟體升級,只要對應的閘門尚未啟用,新功能就不會實際生效。

先看時隙縮短的進度。Solana目前的時隙時間為400毫秒,計畫分四個階段、每階段各縮短50毫秒,最終降至200毫秒。Agave 4.2鎖定的350毫秒、300毫秒閘門,已分別在測試網的第1000、1002個epoch,以及開發網的第1115、1118個epoch啟用,但主網的啟用epoch目前仍未有紀錄。250毫秒閘門還在等待進入開發網,200毫秒閘門則連測試網都尚未通過。網路同時設有安全機制,一旦區塊生成失敗率(跳過率)上升,縮短時隙的程序就會暫停。業界人士解釋,時隙縮短通常能提高出塊頻率、縮短交易處理延遲,但驗證者之間的通訊延遲一旦拉長,跳過率上升的風險也會隨之增加。

再看外界最關注的租金費用調整。這項變化的做法,是把決定鏈上儲存成本的常數(lamports_per_byte)從6,960調降至696。不過所謂「降低90%」指的是全部階段完成後的最終狀態,實際上會分成6,333、5,080、2,575、1,322、696共五個階段依序調整。根據Solana基金會的租金說明頁面,截至8月17日,這五個閘門在主網上全數尚未啟用。租金是帳戶為了在鏈上保留資料所支付的費用,業界普遍解釋,這項常數一旦調降,開發者與用戶在儲存資料時的負擔就會減輕,進而影響去中心化應用(dApp)與代幣發行的成本。

大額交易規格同樣尚未在主網定案。新版v1交易格式原訂將最大負載量從1,232位元組提高到4,096位元組,但主網啟用時程尚未確定,既有的legacy與v0格式上限則維持不變。

至於備受矚目的共識協議升級方案Alpenglow,目標是把交易最終確認時間從現行Tower BFT的12.8秒大幅縮短至100至150毫秒,但在Agave 4.2中僅納入程式碼。Solana基金會在Agave 4.2的發布說明中表示,Alpenglow的主網啟用將留待Agave 4.3階段進行,4.3的目標時程為2026年10月。本刊此前已報導,Alpenglow是把12.8秒最終確認時間壓縮至100至150毫秒的獨立共識協議轉換方案,將於4.3階段處理。此前本刊也曾報導,Agave 4.3的主網測試版功能預計自9月起啟用,但依Solana基金會最新官方文件,目標時程已標示為10月,顯示各階段啟用範圍仍有必要分開確認。

驗證者雖已陸續將軟體升級至Agave 4.2,但這僅代表系統具備了處理新規則的準備,並不等於時隙已經加快、租金已經調降。對dApp開發者而言,若要以大額交易或更短的最終確認時間為前提設計服務,同樣必須等到對應閘門在主網正式啟用。

這項區分之所以重要,是因為8月17日這個日期本身,對用戶與開發者來說並不代表任何事情已經確定。唯有各項功能閘門的主網啟用epoch被正式記錄下來,才能確認路線圖究竟有哪些部分真正進入了生產環境。

Solana先前將單一區塊最大運算單元(CU)上限提高至1億的升級,也是先經過測試網與開發網驗證,才分階段套用到主網。Agave 4.2的時隙縮短與租金調降,目前依循的正是同一套驗證流程。

整體而言,Agave 4.2在軟體部署層面已在推進,但租金調降與時隙縮短這類實質變化,仍須經過各自閘門依序啟用的獨立程序。接下來需要持續確認的重點,一是Agave 4.2剩餘閘門何時真正在主網啟用,二是目標訂在10月的Agave 4.3,是否會讓Alpenglow正式上線。