Solana 目標在 9 月 9 日推出 Transaction v1，這是一種新格式，可將最大序列化交易大小從 1,232 位元組提高到 4,096 位元組。
摘要
- Solana 計劃在週三主網上將最大交易大小從 1,232 位元組提高到 4,096 位元組。
- Transaction v1 仍然是可選的，而 legacy 和 v0 格式繼續在現有大小限制下運行。
- 讀取區塊的應用程式必須支援版本一，否則在遇到新格式時可能出現錯誤。
- V1 移除了位址查找表，並將資源限制直接儲存在每個交易的配置元資料中。
- Solana 的官方路線圖將主網啟動標記為待定，因此 9 月 9 日的時間表仍可能變更。
這一增加為開發者提供了約 3.3 倍的交易空間。Solana 的官方路線圖表示，額外的容量可以容納零知識證明、大型多重簽名操作、批次和一些鏈上簽名方案。
以前，當大型操作的指令、簽名和帳戶資訊超過 1,232 位元組的上限時，必須將其分成多個交易。這個過程增加了複雜性，因為一個交易可能成功而另一個步驟失敗。
Transaction v1 可以讓開發者將更多這些指令合併到一個原子操作中。要么每個指令都成功，要么整個交易失敗。這種模式可能有利於交易路線、保密轉帳、跨鏈操作以及處理複雜加密證明的應用程式。
此次升級不會提高 Solana 每個交易最多引用 64 個帳戶的限制。應用程式可以包含更多資料和指令，但不能自動與更多帳戶互動。
現有的 Solana 交易將繼續有效
Transaction v1 是可選的。錢包和應用程式可以繼續在現有的 1,232 位元組限制下發送 legacy 和 v0 交易。用戶在啟動前無需遷移代幣、兌換 SOL 或完成領取。
開發者必須刻意採用新格式才能使用其更大的容量。Solana 文件識別了三種支援的格式：legacy、v0 和 v1。每種格式以不同方式組織帳戶位址和資源限制。
v0 格式使用位址查找表（ALT）透過壓縮的一位元組索引來表示帳戶位址。V1 移除了 ALT，並將完整的 32 位元組帳戶位址直接放入交易中。
這產生了一種取捨。V1 提供了更大的整體信封，但嚴重依賴查找表的應用程式可能花費更多位元組來表示相同的帳戶。Solana 的技術分析發現，90% 的抽樣交易從 v0 轉換為 v1 時，增加的字節數少於 1,400 位元組。
基礎設施提供者必須更新其軟體
主要的相容性風險適用於讀取區塊和交易的服務。遠端程序呼叫提供者必須將其支援的最大交易版本設定為一。否則，當遇到 v1 交易時，請求可能失敗。
索引器、瀏覽器和分析服務也必須更改其檢索資源限制的方式。Legacy 和 v0 交易將計算限制和優先費用設定放在 ComputeBudget 指令中。V1 將它們儲存在專用的交易配置中。
過時的服務因此可能顯示不正確的資訊。例如，區塊瀏覽器可能顯示零優先費，即使使用者已支付費用。費用贊助者和檢查交易限制的應用程式必須讀取新的設定，而不是掃描舊式指令。
發送 v1 交易的應用程式必須明確設定計算單元和載入資料限制，因為兩者預設為零。開發人員應在將生產流量轉移到該格式之前，測試交易的建構、簽名和解碼。
9 月 9 日仍是目標啟用日期
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 符合驗證器硬體常用的記憶體頁面大小。較大的交易也將消耗額外的頻寬，儘管此升級並未引入按位元組單獨收費。
Transaction v1 與 Solana 的租金調降、較短的時隙目標和 Alpenglow 共識重新設計保持分離。在相關報導中，crypto.news 報導Alpenglow 目標約 150 毫秒的最終性，10 月仍是開發目標，而非保證的啟用日期。
