Solana v1 交易詳解：大小限制與重大變更

Quicknode

2026年9月1日 — 閱讀時間 10 分鐘

分享

新增為首選來源

開發者在Solana 上建置複雜應用程式時，多年來一直設法繞過交易大小限制。v0 版本引入了地址查表機制，讓交易能在不超過 1,232 位元組的情況下，參考更多帳戶。最新升級版本推出了 v1 交易，將限制本身提高了 3.3 倍。

「Transaction v1」將序列化交易的最大大小從 1,232 位元組提升至 4,096 位元組，並將於 2026 年 9 月初隨 Agave v4.2 正式啟用。對於正在開發零知識（ZK）應用程式、多簽名系統及複雜 DeFi 基礎元件的團隊而言，這額外的空間將消除一整類的權宜之計。

即使沒有採用 v1，也會受到其影響。凡是讀取Solana 資料的系統，無論是否曾傳送過 v1 交易，都會受到影響。

1,232 位元組的限制源自 UDP。Solana 早在數年前便已將交易處理移轉至 QUIC，此舉本應消除該限制。然而，該限制卻依然存在。各團隊仍持續將交易拆分、建立查表機制，並在一個已不再與底層傳輸協定相符的上限下進行系統建構。

新的限制並非基於網路限制。4,096 位元組與驗證者記憶體頁對齊。這為 ZK 證明、BLS 簽名方案、保密轉帳、預言機價格更新請求，以及在單一交易中容納更多指令（無需使用捆綁方案）騰出了空間。此外，它還能完整內嵌 64 個帳戶的資料集，這正是 v1 完全捨棄地址查表（Address Lookup Tables）的原因。

什麼是Solana v1 交易？

v1 交易是一種新的Solana 電匯格式，上限為 4,096 位元組。它並非上限較高的 v0 版本，兩者之間有五項差異：

• 版本位元組 0x81 位於偏移量零處，因此任何使用者都能透過單一位元組識別該格式

• 簽名將移至交易尾端，而非置於訊息之前

• 固定寬度 u8 計數取代 compact-u16 編碼

• 指令的標頭會預先與其有效載荷分組，使得邊界可直接計算出來

• 資源限制移入標頭配置遮罩中

位址查詢表已不復存在

v1 版本中已移除對地址查詢表（Address Lookup Tables）的支持。現在每個帳戶皆以完整的 32 位元組公鑰形式內嵌傳輸，而最多 64 個地址所佔用的空間為 2,048 位元組，這僅相當於新增單一指令前新信封大小的一半。

Solana 我們針對mainnet 的流量進行了成本測量。約 62% 的 v0 交易至少引用了一個查詢表。轉換為 v1 後，其中一半的交易額外佔用不到 420 位元組，90% 的交易則不到 1,400 位元組。那些引用多個查詢表、卻僅提取少量地址的交易，其大小反而會變小，因為查詢表的開銷高於壓縮所帶來的節省。

移除查閱表也能簡化驗證器的資料導入流程。v0 版本會在驗證器甚至還不知道交易涉及哪些帳戶之前，就強制進行基於狀態的表解析。v1 版本則直接將交易中的完整帳戶集傳遞給驗證器，因此手續費和優先級的計算能更早進行。

額外的位元組能帶來什麼好處

載荷豐富的應用程式獲得了更大的容量，因為證明和指令資料會消耗位元組，卻不會佔用帳戶槽位。至於帳戶密集型的應用程式（包括多場域路由和廣泛的協定組合），則將大部分新增空間用於重新內嵌先前由查表表壓縮的位址。對於這些團隊而言，64 個帳戶的上限現已成為限制性約束，因此繼續使用 v0 版本是個合理的選擇。

位元組是 v1 版本中唯一的限制。帳戶數維持在 64，指令數維持在 64，簽名數則維持在 12。

讀取Solana 資料時會發生什麼問題

當應用程式讀取或索引Solana 中的資料時，若其查詢的區塊中首次出現 v1 交易，該應用程式將會失敗。從前端讀取交易的程式碼會讀取訊息資料中原本存放舊版（legacy）與 v0 簽名的位置，因此無法透過提高長度檢查來修復解析器。

getBlock 和 getTransaction 會拒絕 v1 交易

未聲明支援 v1 的呼叫會返回錯誤 -32015 一旦觸及其中一筆，整個區塊讀取作業便會失敗。索引器與回填工作會停止執行，而非跳過那筆無法解析的交易。設定 maxSupportedTransactionVersion：1 在這兩次呼叫中，作為 JSON 整數 1. 該字串 "1" 失敗了，而……也是如此 0，因此，在 v0 推出期間選擇啟用 v0 支援的程式碼尚未涵蓋在內。 getSignaturesForAddress 不會受到影響，因為它從不檢查交易主體。

那個中斷的通話：

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getBlock",
    "params": [402184291, { "encoding": "json" }]
}

相同的呼叫，已修正。除了版本參數之外，還必須使用 Base64，因為 Base58 無法編碼超過 1,232 位元的交易：

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getBlock",
    "params": [
        402184291,
        {
            "encoding": "base64",
            "maxSupportedTransactionVersion": 1
        }
    ]
}

blockSubscribe 停止推進

blockSubscribe 釋放 null 當它遇到 v1 交易時便會卡住，且沒有可擷取的錯誤。基於錯誤率建置的監控機制從未觸發，因此訂閱會在第一個 v1 時槽處卡住並維持該狀態。設定 maxSupportedTransactionVersion：1 關於訂閱，請處理 區塊：null 將其視為失敗而非空區塊，並新增過期檢查，因為否則將無法偵測到此問題。

ComputeBudget 掃描結果顯示全為零

v1 將運算限制和優先級費用從指令中移出，改為在訊息層級進行配置。掃描 ComputeBudget 指令的索引器將無法找到匹配項目，並會將零寫入每個下游資料集，且在任何層級均不會觸發錯誤。請改為從交易配置中讀取限制值。此配置會出現在已選擇加入的回應訊息中，但在舊版及 v0 中則完全不存在。未設定的欄位將保持原樣 null:

"message": {
    "instructions": ["… no ComputeBudget instruction here …"],
    "recentBlockhash": "GsdgFbNBoZmAB5uPHfk2xUFYyM4Wg2hYZBfBrxrqjxfF",
    "transactionConfig": {
        "computeUnitLimit": 30000,
        "heapSize": null,
        "loadedAccountsDataSizeLimit": 200000,
        "priorityFee": null
    }
}

優先權費用彙總在單位變更時會中斷

Legacy 和 v0 將手續費以每計算單位的微拉姆波特表示；v1 則以拉姆波特的絕對總額表示。若要將兩者整合至同一儀表板中，請將 v0 的價格乘以該筆交易所要求的計算單位上限，再除以 1,000,000：

20,000 CU × 250,000 微型 lamport/CU = 5,000 lamport   // v0
                                        5,000 lamport   // 等同於 v1

若跳過換算步驟，這些總數便毫無意義。

Geyserstreams 沒有版本限制

串流媒體用戶沒有與之相當的 maxSupportedTransactionVersion 而且無法選擇退出。請將Yellowstone 的 geyser 外掛程式升級至 15.1.1，並在 12.6.0 或更新版本中重新產生 protobuf 存根，這將新增 Message.config 欄位。過期的消費者在 v1 時不會報錯。它會將該交易讀取為 v0，且運算預算為空。

透過結構化方式偵測版本，位於 Message.config，並依照以下順序檢查：

順序很重要，因為 已版本化 這對 v0 和 v1 皆成立。若先進行測試，系統會將每筆 v1 交易默默地歸類為 v0，並將其運算預算設為零。

function messageVersion(message: Message): "legacy" | "v0" | "v1" {
    if (message.config !== undefined) {
        return "v1";
    }
    return message.versioned ? "v0" : "legacy";
}

config 這是一個子訊息，而在 proto3 中，子訊息欄位總是明確地包含「存在」資訊，因此無論解碼器如何處理預設值，此檢查皆成立。

較舊的Yellowstone 版本將 v1 降級為 v0

Yellowstone 15.1.1 版本之前的 geyser 外掛程式，會在 v1 交易傳送至網路之前，將其轉換為 v0 格式。資料流仍會持續運作，但其傳輸的內容將不再與鏈上實際執行的內容相符。請升級至 15.1.1 或更新版本，並在使用舊版建置時，針對任何曾將資料流資料與鏈上狀態進行對帳的流程，妥善處理此差異。

傳送 v1 交易時會發生什麼問題

無論equipe 是否採用 v1，上述錯誤都會發生。但這些錯誤不會發生。在應用程式自行建構並提交 v1 交易之前，以下情況均不會發生；且每項變更皆涉及交易建構方式的調整，而非讀取方式的變更。舊版及 v0 交易仍會以 1,232 位元組的尺寸照常運作，因此是否傳送 v1 取決於容量考量。若交易所需空間超過 1,232 位元組，則別無選擇。

若未設定資源限制，預設值為零

當交易未指定任何參數時，Legacy 和 v0 版本會預設採用每條指令 200,000 個運算單位，以及 64 MiB 的載入帳戶資料。v1 版本則會預設為零，並導致交易失敗。每筆 v1 交易都會明確設定運算單位上限與載入帳戶資料大小上限。在 @solana/kit 8.0 將這些內容從 ComputeBudget 指令移至訊息設定中：

import { setTransactionMessageConfig } from '@solana/kit';

const message = setTransactionMessageConfig(
    {
        computeUnitLimit: 20_000,
        loadedAccountsDataSizeLimit: 64 * 1024,
        priorityFeeLamports: 5_000n,
    },
    baseMessage,
);

從一次模擬執行中測量兩個極限值（各自設定為最大值），然後寫入返回的 已消耗單位數 以及 已載入帳戶資料大小 回到設定檔中。將資料大小向上取整至下一個 32 KiB 頁面。由於區塊成本模型是以 32 KiB 頁面為單位計費，因此低於下一個邊界的餘裕空間是免費的。

請預留比模擬結果所顯示的空間還多的餘裕。不存在的帳戶載入時不會佔用任何空間，但一旦建立，便會佔用 64 位元組加上其資料的空間，因此若限制大小完全與模擬結果相符，將會導致錯誤： 已超過最大載入帳戶資料大小 如果帳戶在交易入帳前就出現了。

ComputeBudget 指令會變成無操作

v1 會接受這些指令，每條收取 150 個運算單位，並在配置時忽略它們。若某筆交易包含 ComputeBudget 指令卻未包含訊息配置，該交易將通過驗證，並在無任何限制的情況下執行。請將這些指令完全從 v1 建構器中移除。訊息配置已取代了這些指令，而每保留一條，便會佔用 64 個可用指令槽中的 1 個，並消耗 150 個運算單位，卻毫無作用。

優先權費用

v1 將優先級費用設定為絕對的拉姆波特總和。v0 中「每計算單位的微拉姆波特」的計算方式並未沿用。該值為 bigint 型別，且在舊版及 v0 訊息中，該設定器會在編譯時被拒絕：

import { setTransactionMessagePriorityFeeLamports } from '@solana/kit';

const message = setTransactionMessagePriorityFeeLamports(5_000n, baseMessage);

Base58 編碼的上限為 1,232 位元組

超過該金額的交易需要 編碼："base64" 在提交時。若申請中硬編碼了 base58，則在 v1 啟用的大型交易中會導致失敗。

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "sendTransaction",
    "params": [
        "<base64-encoded transaction>",
        { "encoding": "base64" }
    ]
}

重複的地址將被拒絕

Legacy 和 v0 允許同一筆交易中出現重複的帳戶地址，而 v1 則會拒絕此類情況。

哪些客戶端版本支援 v1？

v1 的支援服務自 @solana/kit 8.0.0、4.2.x 版本的 Rust 套件、solders 0.29.0，以及solana-go 1.23.0。

v1 格式目前已在本地驗證器上運行，無需啟用任何功能閘門。 solana-測試驗證器 自 4.2 版起支援此功能，Surfpool 自 1.5 版起支援，以及一個 針對 SIMD-0296 進行配置的暫存 Surfnet 提供託管方案。

Quicknode 對 v1 的支援

Quicknode RPC 端點和 API 在啟用時即支援 v1 交易。無需進行endpoint 遷移、變更計畫、設定標記或提交支援票證。

Quicknode 目前 Alpenglow 叢集已支援 v1 交易，因此該格式可在送至testnet 之前，先透過實際運作的endpoint 進行測試。Testnet 尚待SIMD-0385 Transaction V1 啟用，預計於 2026 年 9 月 2 日星期三 UTC 時間 10:30 進行。

剩餘的工作在於應用程式程式碼中。傳遞 maxSupportedTransactionVersion：1 於 getTransaction 以及 getBlock, 請升級至上述列出的客戶端版本，將 ComputeBudget 指令掃描功能替換為訊息配置，統一各格式中的優先級費用單位，並針對超過 1,232 位元的交易改用 base64 編碼。