Solana 交易錯誤：過期 Blockhash 與未落塊交易

2026-08-12

一筆 Solana 交易可以同時在多個層次上被描述。訊息描述擬執行的指令及其上下文，已簽名交易攜帶對該訊息的授權，RPC 回應報告某個服務已接受或觀察到的內容，而集群記錄則是在指定承諾級別上的證據。這些層次可以產生不同的狀態措辭而並不互相矛盾。因此，理解過期或未落塊交易訊息，首先要辨明是哪個層次產生了它。本地逾時、RPC 錯誤、狀態回應和已最終確定的記錄，描述的是提交路徑上的不同位置，並不是對最終狀態的一種通用結論。

交易狀態與提交路徑

一筆 Solana 交易包含指令、授權變更的帳戶簽名和 recent blockhash。網絡在處理交易時會將其中的指令視為一個原子整體：任何一條指令失敗，預期的狀態變更就不會作為整體被寫入。在這一結果存在之前，交易還可能經歷訊息形成、簽名、轉交給 RPC 節點、被網絡參與者接收、處理，以及在某一承諾級別上被觀察到等不同階段。只有明確了所處階段，狀態標籤才有意義。

sendTransaction RPC 方法在 RPC 服務接受已簽名載荷以便轉發時報告第一筆交易簽名。官方文件明確將這種即時接受與集群的處理或確認區分開來。在一般討論中，未落塊交易常指早先出現過某個與提交有關的事件，卻沒有隨後的集群記錄。它不是只有一個固定原因的單一共識狀態。該詞可能由客戶端、RPC 服務或觀察者使用，而它們所指的可能是路徑中不同的一段缺失轉換。

Blockhash 的作用

交易訊息中的 recent blockhash 是由網絡提供的新鮮度參照。getLatestBlockhash 方法同時返回 blockhash 和 lastValidBlockHeight，將這一參照連接到高度邊界，而不是連接到有保證的自然時間長度。這使協議能夠判斷攜帶該參照的交易是否仍在處理窗口內。blockhash 是正在被評估的訊息的一部分，因此它屬於交易的身份與驗證上下文，而不是後來區塊瀏覽器上的顯示內容。

區塊高度、slot 推進和經過的時間彼此相關，但不應被當成可以互換的時鐘。文件所述的確切處理年齡參數、slot 數量，以及這些 slot 所代表的經過時間，都取決於相關協議和軟件版本以及網絡條件。因此，更恰當的理解是，recent blockhash 提供一個依賴版本的有效性窗口。穩定的事實是存在邊界，而精確時長不是通用承諾。

已過期與找不到並不相同

已過期描述的是一種有效性結果：依照適用規則，recent blockhash 已不能再讓交易被處理。它關乎交易受時間限制的參照，而不是每一次轉發失敗或記錄缺失的通用標籤。人們使用搜尋短語 solana transaction expired 時，常是在稱呼一個映射到這個生命週期邊界的客戶端可見結果。僅憑該短語，無法說明某個 RPC 節點具體接收了甚麼，也不能說明存在獨立的轉帳結果。

blockhash not found solana 是常將顯示字串與網絡名稱放在一起的搜尋短語。實際的 blockhash-not-found 訊息可能表示，一個節點在其當前視圖和承諾級別下，無法為相關驗證上下文解析所引用的雜湊。這一觀察並不自動等同於最後有效區塊高度已經在所有地方過去的證明。節點狀態、承諾級別、API 版本、時點和客戶端措辭都會改變廣泛條件被呈現的方式，因此不應把這兩個短語壓縮成同一個不變診斷。

已簽名但尚未落塊

簽名是對特定訊息的授權；它不是該訊息已到達區塊的記錄。同樣，RPC 服務接受載荷以供轉發，也不是集群已經處理它的記錄。因此，一筆已簽名交易可以被稱為已簽名，卻仍沒有已處理、已確認或已最終確定的觀察結果。僅憑這段空缺，無法揭示一個載荷是從未被相關參與者接收、未被保留在可見的狀態範圍內，還是在能夠被處理前失效。

JSON-RPC 狀態方法把觀察範圍的限制明確展現出來。getSignatureStatuses 為所提供的簽名返回當前狀態，除非包括交易歷史搜尋，否則其預設搜尋局限於近期狀態快取。getTransaction 按簽名返回已確認交易，或者在請求的承諾級別下未找到或未確認時返回 null。因此，null 回應是一個有範圍的回應，並不是對每個節點保留視圖中從未存在任何事件的通用陳述。

RPC、客戶端與網絡觀察的差異

客戶端介面通常把多個技術信號壓縮成供人閱讀的簡短句子。RPC 回應則是特定節點的報告，帶有上下文 slot、API 版本、配置和請求的承諾級別。網絡觀察指的是相關承諾級別使其可見的狀態。這些觀察彼此有關聯，但不是同一個物件，也不需要在同一時刻變得可見。

版本依賴在每一個層次都很重要。Solana 節點軟件、客戶端程式庫、RPC 配置、交易版本支援、承諾級別預設值、狀態保留和介面措辭都可能演變。因此，穩健的解釋會先識別觀察者及觀察範圍，再為錯誤標籤賦予含義。它不會把一個介面中的短語當作對每個節點、每個承諾級別或每個軟件版本都可移植的描述。

為什麼重複提交不是通用答案

重複提交並不是一個單一的技術事件。它可能是再次轉發同一份已簽名字節、呈現不同的訊息，或生成具有不同驗證上下文的後續訊息。這些情形擁有不同的標識、時點和可能的狀態影響。網絡正在考慮的一筆交易與一筆表達相似意圖但之後生成的不同交易，並不會僅因意圖相似就能互換。因此，重複會使可見簽名、狀態記錄與預期狀態變更之間的關係更難解釋。

出於同樣原因，通用的重試處方會把接收、傳播、驗證、執行和承諾級別混成一個概念。過期措辭本身不能確立後續訊息會與較早訊息擁有相同的身份或影響。從分析角度看，重要的區別在於可獲得的證據指向同一交易訊息、另一條獨立訊息，還是僅指向一次本地轉發資料的嘗試。本文關注的是這種區別，而不是發送另一筆交易的程序。

穩定的排查詞彙與風險邊界

穩定的詞彙有助於讓各層次保持分離。訊息指被授權的指令、帳戶、recent blockhash 和其他資料。簽名為面向狀態的 API 標識已簽名交易。提交指 RPC 轉發事件，而處理、確認和最終確定指不同層次的網絡觀察。承諾級別是 RPC 方法使用的請求可見性門檻。過期關乎新鮮度參照，未落塊通常描述不完整的已觀察路徑，而不是只有一種標準化含義的協議裁決。

這些術語的邊界與其定義同樣重要。技術狀態不能確立帳戶所有權、發送者意圖、資產餘額、服務行為，或缺失記錄的補救措施。它也不能把客戶端訊息變成每個驗證者或每個資料保留系統所觀察到內容的證明。狀態語言是關於有限處理路徑的證據，需要通過版本、觀察者、承諾級別和時點來解釋。保持這一邊界清晰，可以避免把狹窄的網絡信號擴展成更廣泛的主張。

風險披露：本文為 Bitbase（幣貝）學院的科普內容，僅供教育與資訊參考，不構成任何投資、交易、稅務或財務建議。加密資產波動劇烈，請自行評估風險。本文撰寫於 2026 年 8 月，請以官方最新資訊為準。