Solana 週二在主網啟用 Transaction V1 功能，允許每筆交易納入更多資料。這項升級為開發者在單一原子流程中執行複雜操作提供更多空間，與 DeFi 開發者、錢包供應商、索引器及 RPC 營運商高度相關，也可能影響處理代幣化資產與支付解決方案的專案。

根據 Solana 升級頁面，txv1 功能閘門已在 epoch 1035 開始時、9 月 15 日約 01:00 UTC 部署。Transaction V1 現已在 Solana 主網、測試網及開發網上線。

交易大小從 1,232 提高至 4,096 位元組

最明顯的變化是序列化交易的最大大小增加。Solana 已將上限從 1,232 位元組提高至 4,096 位元組，為交易資料提供約 3.3 倍的空間。

新交易的格式由 SIMD-0296 定義，而 V1 Message Format 則以 SIMD-0385 為基礎。此前，Solana 的交易大小上限受到保守的網路最大傳輸單位（MTU）限制。Transaction V1 脫離 QUIC 對串流大小施加的硬性限制，從而支援更大的交易。

新增的容量旨在支援需要大量交易資料的工作負載，包括零知識證明、大型多重簽名操作，以及使用 BLS 的簽章。正如 Cryptopolitan 先前報導，V1 已於 9 月 1 日在 epoch 1025 部署至測試網，讓基礎設施供應商有時間為主網發布做好準備。

為何單一原子交易很重要

在升級前，遇到 Solana 交易大小限制的開發者有時可以將操作拆分到多筆交易中，或使用 Jito bundles。然而，SIMD-0296 的說明指出，若從協議層級的原子性來看，bundle 並不等同於原生交易。

Transaction V1 允許在單筆交易中放入更多指令與資料。因此，路由、證明驗證及批次處理可以全部成功或全部失敗，而不必分別在不同交易中執行。視操作內容而定，這也可能減少所需的簽章與確認數量。

Address Lookup Table 的取捨

Transaction V1 也改變了交易管理資源及帳戶參照的方式。計算限制與優先費設定已從 ComputeBudget 指令移至交易設定，讓基礎設施供應商更容易存取這些參數。

V1 交易不使用 Address Lookup Tables，因為被參照的帳戶會直接納入交易中。這能簡化交易結構，但也可能增加交易大小。v0 Address Lookup Table 只需要一個位元組的索引，而內嵌公鑰則需要 32 個位元組。

對 Solana Address Lookup Tables 的分析發現，62% 的 v0 交易至少使用了一個 Address Lookup Table。因此，使用多個表格的高密度交易，在帳戶參照直接納入後，大小可能增加超過 1,500 位元組。帳戶上限仍維持在 64 個。

在 Solana 代幣化金融擴張中的作用

這項升級正值 Solana 擴大其鏈上金融角色之際。根據 DeFiLlama，Solana DeFi 領域的總鎖倉價值接近 $5.95 billion，24 小時去中心化交易所交易量則約為 $1.79 billion。

Solana 的 8 月摘要也指出，網路上的現實世界資產價值已超過 $4 billion，分布於超過 350,000 個地址。此外，xStocks 管理的資產已累積超過 $500 million。

交易容量增加本身並不保證採用率會提升。Galaxy Research 觀察到，Solana 代幣所承載的價值中，仍有相當大一部分尚未被使用，而競爭平台在部分快速成長的領域仍處於領先地位。Transaction V1 擴大了開發者能在 Solana 上建立的應用範圍，但用戶、流動性與交易活動之後是否會跟進，仍是尚待觀察的問題。

營運商與開發者需要進行的必要變更

RPC 讀取端應針對 getTransaction 與 getBlock 設定 maxSupportedTransactionVersion: 1。索引器則需要從 transactionConfig 讀取 V1 的計算限制與優先費。

驗證者與 RPC 營運商應執行 Agave v4.2.2 或更新版本。V1 發送端應明確設定計算限制與已載入帳戶限制，並對大於 1,232 位元組的交易使用 base64。

錢包供應商只有在確認其軟體能正確解析並簽署新格式後，才應宣傳支援 V1，並遵循 Solana 的升級指引。原始報導由 Cryptopolitan 發布。