週二，Solana在其主網上實現了Transaction V1功能，使得每筆交易可以添加更多數據。這將爲開發者在一個原子化流程中執行復雜操作提供更多空間。

該開發工作將對DeFi領域的開發者、錢包提供商、索引器和RPC運營商高度相關。新功能可能會影響其他處理代幣化資產和支付解決方案的項目。

如Solana升級頁面所述，txv1功能門控已在9月15日約UTC時間01:00於第1035個epoch開始時推出。Transaction V1現已在主網、測試網和開發網上線。

從 1,232 字節到 4,096 字節

第一個是交易大小限制。現在，Solana 已將序列化交易的最大大小從 1,232 字節提升到 4,096 字節，從而爲交易提供了更多空間（約爲原來的 3.3 倍）。

新的交易格式在 SIMD-0296 中定義，而 V1 的消息格式基於 SIMD-0385。

到現在爲止，Solana 中的限制基於保守的網絡 MTU（最大傳輸單元）限制。現在，脫離 QUIC 中對流大小的硬性限制，使得可以發送更大的交易。

額外的空間將有助於處理那些涉及大量交易數據的工作負載，例如零知識證明、超大的多重簽名操作，以及包含 BLS 的簽名。根據 Cryptopolitan 的報道，V1 於 1025 紀元在測試網啓動（9 月 1 日），從而讓基礎設施提供商有機會爲主網發佈做好準備。

Solana 交易 V1 與 Legacy：解析 4,096 字節升級

爲何“一筆原子交易”很重要

那些發現 Solana 存在交易大小上限的開發者，在某些情況下可以將操作拆分成一系列交易，或使用 Jito bundles。

正如 SIMD-0296 提供的解釋所述，在協議層面討論原子性時，“bundle（捆綁包）”並不等同於原生交易。

通過 Transaction V1，可以在一筆交易中放入更多指令和數據。這樣一來，路由、證明校驗和批處理將要麼全部成功工作，要麼全部失敗，而不會像以前那樣被拆分到不同的交易中分別執行。

在某些情況下，爲了實現操作性能，可能需要更少的簽名和確認。

地址查找表的權衡

V1 也改變了交易管理資源和賬戶引用的方式。

解析 Solana 交易 V1：新的交易佈局

計算限制和優先費（priority fee）設置已從 ComputeBudget 指令遷移到交易設置中，使基礎設施提供商能夠更便捷地獲取這些設置。

由於交易中已包含所引用的賬戶，V1 交易也會移除地址查找表（Address Lookup Tables）。

這有助於簡化交易，但代價是交易大小：因爲 v0 的地址查找表只需要 1 字節的索引，而內聯公鑰需要 32 字節。

通過對 Solana 地址查找表（Address Lookup Tables）的分析發現：62% 的 v0 交易至少使用了一個地址查找表；因此，使用超過一個地址查找表的“稠密交易”將使交易大小增加超過 1,500 字節。64 個賬戶的限制保持不變。

V1 如何融入 Solana 的代幣化金融（tokenized-finance）推進

此次升級發生在 Solana 擴大其在鏈上金融領域的佈局之時。根據 DeFiLlama 的數據，Solana 其 DeFi 板塊中的總鎖倉價值（TVL）接近 59.5 億美元，其 24 小時去中心化交易所（DEX）交易額約爲 17.9 億美元。

Solana 在 8 月的彙總中也提到，網絡上的現實世界資產價值已超過 40 億美元，並分佈在超過 350,000 個地址中。此外，xStocks 的資產管理規模（AUM）已超過 5 億美元。

僅僅因爲有了更大的交易容量，並不意味着會帶來更高的採用率。

Galaxy Research 觀察到，與 Solana 代幣相關的價值中仍有很大一部分尚未被使用，而競爭平臺在一些快速增長的領域仍然處於領先。

因此，V1 擴大了開發者能夠在 Solana 上創建的應用範圍。然而，更難的問題是：用戶、流動性和交易活動是否也會隨之跟上。

運營商現在需要做什麼？

RPC 讀取者應爲 getTransaction 和 getBlock 設置 maxSupportedTransactionVersion: 1；而索引器需要從 transactionConfig 中讀取 V1 的計算限制和優先費。驗證者和 RPC 運營商應運行 Agave v4.2.2 或更高版本。V1 發送方也應顯式設置 compute 和已加載賬戶（loaded-account）限制，並對超過 1,232 字節的交易使用 base64。與此同時，錢包提供商應僅在確認其軟件能夠正確解析併爲新格式簽名之後，才宣稱支持 V1——這符合 Solana 的升級指導。

如果你正在閱讀這份內容，你已經走在前面了。請繼續關注我們的通訊。