Solana Transaction v1 週三上線，交易容量擴至4096位元組

Solana 將於週三上線 Transaction v1，將最大交易容量從 1,232 位元組飆到 4,096 位元組。一次完成複雜證明、多簽審批與機密轉帳，開發者不用再拆多筆交易。

（前情提要：從 Memecoin聖地到華爾街新寵，Solana 邁上轉型之路）

（背景補充：Solana 反攻 Meme 戰場：STONK、ZCAT 雙破億，官方親自下場喊單）

索拉納（Solana）將於本週三（9 月 9 日）正式上線 Transaction v1 功能，將最大交易容量從 1,232 位元組直接拉到 4,096 位元組，成長超過三倍。

這項升級定義在兩份改善提案：SIMD-0296（更大交易）與 SIMD-0385（Transaction v1 格式），由 Jacob Creech 與 Andrew Fitzgerald 共同撰寫。新功能已在測試網與開發網穩定執行一段時間。

什麼場景最需要三倍容量？

Transaction v1 最直接的受益者是需要打包大量指令的交易型別： 大型密碼學證明：ZK proof 等驗證資料以往常因超過 1,232 位元組限制而被迫拆成兩三筆交易，現在可一併送出。

多簽審批流程：需要多位簽名者批准的資金轉移（如企業金庫、DAO 提案），每個簽名都佔用空間，v1 讓審批流程能在單一交易完成。

機密轉帳：部分隱私交易機制需要額外的加密包裝，容量不足時會導致交易失敗或效率低落。

開發者不需強制切換：現有的 v0 交易格式繼續有效，錢包與應用只在需要更大空間時才改用 v1。

為什麼是 4,096 位元組，不是更多？

上限定在 4KB（4,096 位元組）有硬體層面的考量：這是驗證者節點使用的標準記憶體頁面大小。單筆交易若跨越多個頁面，處理成本會顯著上升，對維持 Solana 的高 TPS（每秒交易量）不利。

舊的 1,232 位元組限制則來自 Solana 早期的網路設計，每筆交易必須塞進約 1,280 位元組的 IP 封包內。2022 年 Solana 調整了交易流量的傳輸方式，那個硬性天花板已不再必要。

對讀取鏈上資料的服務影響更大 這次升級對「讀 Solana」的軟體比「寫交易」的軟體影響更大。所有抓取區塊與交易資料的服務（RPC 節點、鏈上資料供應商、錢包後端）都必須更新程式碼，否則遇到 v1 格式的交易會直接回傳錯誤。

另一個陷阱在優先費（priority fee）的顯示位置：v1 把優先費資訊存在不同的欄位，舊版軟體會顯示為「零費」，即使使用者實際上付了加速費。錢包、區塊鏈瀏覽器與交易 APP 的螢幕顯示資料若沒更新，使用者會看到錯誤資訊。

與以太坊比，Solana 還差在哪？

從結構面來看，Solana 過去最弱的一環就是交易容量硬上限。以太坊沒有協議層的交易大小限制，開發者只要願意付更高的 Gas 費，就能在單一交易內執行龐大的資料密集型操作。

三倍擴容後，Solana 在「單筆交易能塞多少指令」這件事情上大幅縮短差距。不過 4,096 位元組對以太坊來說仍然不算大，以太坊 L1 上一筆複雜的 DeFi 組合交易（如 Uniswap 多池套利、Aave 多資產借還）經常超過這個數字。

對 Solana 生態來說，這次升級的實際意義在於「消除開發者的 workaround」：過去必須把操作拆成多筆交易時，需要處理跨交易的狀態依賴、失敗回滾問題；現在可以像寫傳統程式一樣，在一個原子操作中完成複雜邏輯。