Solana 於 9 月 15 日 epoch 1035 開始時、約 01:00 UTC 在主網啟用 txv1 功能。此次升級將最大交易大小從 1,232 bytes 提高至 4,096 bytes，容量超過原先的三倍。

新增空間透過 V1 交易格式提供。應用程式必須明確加入支援後才能使用該格式，而 legacy 與 V0 交易仍在原有限制下獲得完整支援。

較大的交易不代表較大額的 SOL 轉帳

新限制涉及交易所承載的資訊量，而不是使用者可以傳送的 SOL 數量。標準轉帳通常只需要有限資料，因為其中僅包含少量帳戶、指令與簽章。

較複雜的操作可能需要多個指令、大量帳戶地址、多重核准或密碼學證明。當這些資訊超過原有限制時，開發者必須縮減資料負載、將操作拆分至多筆交易，或使用帳戶查找表與交易捆綁等替代方案。

Solana 能夠平行處理彼此無關的交易，詳見這份 Solana 運作方式指南。V1 不會改變這種執行模型，而是在單一操作必須包含多個相互關聯的元件時，提供更多空間。

當這些指令以一筆原子交易提交時，會作為一個整體處理。完整操作要麼成功，要麼其變更被回復，從而避免只有部分指令抵達帳本的情況。

哪些操作可能受益於額外空間？

• **批次交易：**交易應用程式可以將相互關聯的指令放入一筆交易，而不必協調多次確認。
• **大型 multisig 核准：**當多人必須授權一項操作時，財庫與企業錢包可以容納更多簽章及帳戶資訊。
• **零知識證明：**應用程式可以在不揭露所有底層資訊的情況下證明某項條件已獲滿足，但證明本身可能需要大量交易空間。
• **鏈上簽章方案：**部分密碼學簽章格式過去產生的資料量，超過單筆 Solana 交易所能容納的大小。

Solana Foundation 將機密轉帳、巢狀 multisig、批次操作及某些鏈上簽章方案列為新格式的潛在用途。

大多數錢包使用者無需採取行動

啟用這項功能不要求使用者轉移 SOL、建立另一個地址或轉換現有帳戶。繼續使用 legacy 或 V0 交易的應用程式，應會如升級前一樣運作。

當應用程式選擇傳送 V1 交易時，使用者需要相容錢包。隨著服務提供商推出支援，持續更新錢包軟體將可取得這項功能，但應用程式仍應在要求錢包簽署前檢查相容性。

對使用者而言，這項變更最終可能表現為複雜操作所需的核准請求減少。過去需要多筆相互關聯交易的服務，可能改為提出一個請求並等待一次確認。

開發者與索引器必須更新軟體

傳送 V1 交易屬於選擇性操作，但讀取 V1 交易可能為尚未更新的基礎設施帶來相容性問題。

讀取交易或區塊的 RPC 服務必須設定 maxSupportedTransactionVersion: 1。若未設定，請求 V1 交易可能回傳錯誤；單筆不受支援的交易也可能導致請求完整區塊時失敗。

索引器面臨不同風險。V1 將其運算上限、載入帳戶資料上限及優先費儲存在 transactionConfig 中，而不是 Compute Budget 指令內。若軟體仍掃描舊位置，可能會錯誤分類交易，或將其資源上限與優先費回報為零。

建立 V1 交易的應用程式必須明確設定運算單位及載入帳戶資料上限。在新格式中，這兩項數值預設為零，因此省略設定可能導致交易在執行前失敗。

大於 1,232 bytes 的交易也必須使用 base64 編碼提交。base58 提交路徑仍保留原有的大小上限。

V1 增加空間，但也改變其他限制

V1 並不只是負載更大的 V0。它可以在交易中直接包含最多 64 個帳戶地址，但不支援帳戶查找表。重複的帳戶地址也會被拒絕。

這些規則為應用程式團隊帶來不同的設計選擇。當查找表能有效率地參照帳戶時，V0 仍然有用；V1 則適合能從額外指令、簽章或證明空間中受益的操作。

基本付款不太可能從新格式中獲益。當應用程式可以取代複雜流程，或容納過去完全無法放入單筆交易的資料時，V1 才更適合使用。

較大型交易可能帶來更高費用

提高 bytes 上限不會自動使每筆 V1 交易變得更昂貴。成本取決於所要求的資源、簽章數量及應用程式選擇的優先費。

較大的訊息確實會消耗更多驗證者頻寬。Solana 的文件表示，對於尋求相同優先級的大型交易，排程器預期會要求其支付高於小型交易的優先費，尤其是在區塊空間需求旺盛時。

V1 將優先費表示為 lamports 的總額。V0 則使用每運算單位的價格，這意味著分析平台在比較兩種格式前，必須先將其標準化。

如Solana 最近的費用資料所示，優先費需求可能隨網路活動大幅變化。因此，開發者需要權衡以一筆較大操作帶來的便利性，與在網路壅塞期間讓該操作被納入區塊的成本。

啟用功能開啟採用測試

此次升級移除了過去影響 Solana 應用程式建構方式的一項限制，但主網啟用並不保證會獲得廣泛採用。錢包、RPC 提供商、索引器及應用程式函式庫必須正確處理新格式，開發者才能在面向客戶的產品中依賴這項功能。

最早的效益可能出現在已受原有上限限制的工作負載，包括機密轉帳、機構 multisig 安排及指令密集型應用程式。對一般轉帳而言，既有格式仍是較簡單的選擇。

V1 的重要性將取決於：將這些工作負載放入一筆原子交易後，在協調、簽章及失敗嘗試方面節省的成本，是否足以抵銷所需的基礎設施更新。

本文僅供資訊參考，不構成財務或投資建議。錢包相容性、應用程式支援及交易費用均可能變動。

來源：Coindoo