Solana 目標在 9 月 9 日推出交易 v1，這是一種新格式，將最大序列化交易大小從 1,232 位元組提高到 4,096 位元組。
此次增加為開發人員提供了約 3.3 倍的交易空間。Solana 的官方路線圖表示，額外的容量可以容納零知識證明、大型多重簽名操作、批次處理以及一些鏈上簽名方案。
大型操作以前必須分成數個交易，當其指令、簽名和帳戶資訊超過 1,232 位元組的上限時。這個過程增加了複雜性，因為一個交易可能成功，而另一個步驟卻失敗了。
交易 v1 可以讓開發人員將更多指令組合成一個原子操作。這意味著所有指令要麼都成功，要麼整個交易都失敗。這種模式可能有益於交易路線、機密轉帳、跨鏈操作以及處理複雜加密證明的應用程式。
此次升級並未提高 Solana 每個交易 64 個參考帳戶的限制。應用程式可以包含更多資料和指令，但無法自動與更多帳戶互動。
交易 v1 是選用的。錢包和應用程式可以繼續在現有的 1,232 位元組限制下發送舊版和 v0 交易。用戶無需在啟用前遷移代幣、兌換 SOL 或完成認領。
開發人員必須特意採用新格式才能使用其更大的容量。Solana 文件指出了三種支援的格式：舊版 (legacy)、v0 和 v1。每種格式組織帳戶地址和資源限制的方式都不同。
v0 格式使用地址查找表 (ALTs) 透過壓縮的單位元組索引來表示帳戶地址。v1 移除了 ALTs，並將完整的 32 位元組帳戶地址直接置於交易內部。
這產生了一種權衡。v1 提供了更大的整體包絡，但嚴重依賴查找表的應用程式可能會花費更多位元組來表示相同的帳戶。Solana 的技術分析發現，90% 的抽樣交易在從 v0 轉換為 v1 時，增加的位元組數少於 1,400 位元組。
主要的兼容性風險適用於讀取區塊和交易的服務。遠端程序呼叫 (RPC) 提供商必須將其支援的最大交易版本設定為一。否則，當他們遇到 v1 交易時，請求可能會失敗。
索引器、區塊瀏覽器和分析服務也必須改變其檢索資源限制的方式。舊版和 v0 交易將計算限制和優先級費用設定置於 ComputeBudget 指令內部。v1 則將其儲存在專用的交易配置中。
因此，過時的服務可能會顯示不正確的資訊。例如，區塊瀏覽器可能會顯示零優先級費用，儘管用戶已支付。費用贊助者和檢查交易限制的應用程式必須讀取新的配置，而不是掃描舊式指令。
發送 v1 交易的應用程式必須明確設定計算單位和載入資料限制，因為兩者預設為零。開發人員應在將生產流量轉移到此格式之前，測試交易的建構、簽署和解碼。
Solana 基金會技術副總裁 Jacob Creech 確認 9 月 9 日為計劃中的主網日期。正如 crypto.news 先前報導，此次升級已包含在 Anza 的 Agave 4.2 發布中。
然而，官方路線圖仍將該主網功能標記為「未啟用」。它還表示 Anza 的發布時間表是「暫定且可能會變更」的。根據基金會的最新狀態頁面，測試網和開發網已啟用此功能。
此次大小增加源於 SIMD-0296，而 SIMD-0385 定義了 v1 格式。Jacob Creech 和 Andrew Fitzgerald 共同撰寫了這兩項提案。
選擇 4,096 位元組的上限部分原因是 4 KB 符合驗證者硬體常用的記憶體頁面大小。較大的交易也將消耗額外的頻寬，儘管此次升級並未引入單獨的按位元組收費。
交易 v1 仍獨立於 Solana 的租金減免、更短的時隙目標和 Alpenglow 共識重新設計。在相關報導中，crypto.news 報導稱 Alpenglow 的目標是約 150 毫秒的最終確定性，而 10 月仍是開發目標，而非保證的啟用日期。
