Solana交易格式將擴至4096位元組 基礎設施相容性受檢驗

Solana(SOL)全新交易格式v1即將在主網啟用之際,業界正針對基礎設施相容性展開檢驗。這次升級將單筆交易的最大容量從1,232位元組提高到4,096位元組,但外界關注的重點不在於鏈上共識是否會出問題,而是RPC、索引器(indexer)、gRPC與手續費代付服務能否正確讀取新格式。

Solana基金會在網路升級頁面說明,Agave 4.2已經部署到主網,但「Larger Transaction Sizes」功能截至2026年9月4日仍處於等待啟用狀態。這項功能透過v1交易格式,將既有交易上限擴大約3.3倍。

這次調整並非單純放大交易容量。提案SIMD-0296與SIMD-0385提出的背景包括大型多重簽名(multisig)、零知識證明(ZK proof)與批次轉帳等應用情境。v1格式減少了舊版交易對地址查找表(address lookup table)的依賴,並將手續費與資源限制資訊移到獨立設定值transactionConfig之中。

問題在於既有系統的讀取方式。若索引器與手續費代付服務只掃描ComputeBudget instruction來計算優先手續費或運算單元(compute unit)上限,就可能漏讀v1交易的手續費上限,甚至將其讀成零。Solana基金會釋出的transaction-v1範例程式庫說明,v1訊息是以TransactionConfig取代ComputeBudget instruction。

Solana的RPC文件指出,呼叫getTransaction、getBlock與blockSubscribe時都必須加入maxSupportedTransactionVersion: 1這項參數。一旦省略該參數或將其設為0,遇到v1交易時getTransaction可能回傳錯誤,getBlock甚至可能整個區塊都讀取失敗。

WebSocket訂閱同樣不能倖免。設定不正確時,blockSubscribe可能回傳block: null。Solana開發文件提醒,這種情況應視為讀取失敗,而非空區塊。v1交易的辨識方式,是序列化交易的第一個位元組為129,即十六進位的0x81。

gRPC與Geyser路徑可能出現更不容易察覺的錯誤。Solana開發文件警告,gRPC並沒有像maxSupportedTransactionVersion這樣的選擇性(opt-in)參數,舊版protobuf存根(stub)甚至可能直接丟棄Message.config欄位。系統雖然不會因此當機,卻可能把v1交易誤判為v0交易,漏掉手續費設定資訊。

Solana基金會的範例程式庫建議的最低版本包括@solana/kit 8.0.0、yellowstone-grpc-proto 12.6.0與yellowstone-grpc geyser 15.1.1,並分別提供讀取、發送、區塊索引與gRPC的範例程式。

核心工具鏈方面的驗證也在持續。anza-xyz旗下solana-sdk儲存庫的第831號issue指出,v1格式4,096位元組的上限,在反序列化器(deserializer)與淨化器(sanitizer)中未被完整強制執行。不過Solana狀態頁面顯示,截至2026年9月4日,主網測試版(Mainnet Beta)RPC節點運作正常,當天沒有通報任何事故。

整體來看,這次事件的性質更接近Solana v1交易容量擴大後的基礎設施相容性檢驗。此前討論聚焦在4,096位元組上限本身與各叢集功能是否啟用,這次則是當真正的v1交易進入網路後,後端系統能否正確讀取新結構。

Solana的升級頁面顯示,截至2026年9月4日,「Larger Transaction Sizes」功能仍處於等待啟用狀態。這項時程與其說是一次性改變Solana處理架構的單一事件,不如說是錢包、RPC、索引器與開發工具需要依序完成準備的技術路徑圖。

就技術層面而言,v1交易並不會取代既有的v0與舊版(legacy)交易格式。舊格式仍會持續運作,但需要使用更大交易容量與transactionConfig的應用程式,前提是必須支援新格式。區塊鏈基礎設施升級向來如此:除了共識規則本身,負責讀取與儲存資料的周邊系統能否相容,才是真正左右營運風險的關鍵。

手續費代付服務與索引器可能首當其衝受到影響。若錯誤讀取手續費上限或運算單元限制,代替使用者支付成本的服務恐面臨與預期不同的費用結構,交易分析系統也可能記錄錯誤的v1交易資源設定。這與整條鏈停擺的故障性質不同,卻是服務營運方必須另外檢查的環節。

若交易所或錢包業者在經營Solana存提款與鏈上監控業務,同樣無法自外於這個問題。相較於交易本身,更需要確認的是區塊與交易查詢、索引、風險監控與手續費計算路徑是否能處理v1訊息結構。特別是使用外部節點服務商或以Geyser為基礎的資料來源時,需要重新產生protobuf並檢查函式庫版本。

在Solana v1交易實際大量出現之前,核心檢查項目包括:△RPC呼叫參數是否設定maxSupportedTransactionVersion: 1、△transactionConfig的儲存路徑是否已更新、△gRPC的protobuf存根是否已重新產生、△系統能否辨識0x81版本前綴。根據Solana升級頁面,「Larger Transaction Sizes」功能截至2026年9月4日仍處於等待啟用狀態。