跳到正文
Financial Context Wiki

如何復原錢包 nonce 缺口

找出 EVM 帳戶第一個缺失的 nonce，判斷應替換還是取消交易，並避免錢包或多部裝置造成交易排隊。

更新於

僅供教育參考，不構成投資建議。投資可能導致損失。

直接回答

在 EVM 相容鏈上，同一個外部擁有帳戶（EOA）送出的交易會依 nonce 順序執行。若下一個可執行 nonce 缺失或卡住，nonce 較高的交易即使費用很高也可能持續排隊。復原時應先處理最低的未解決 nonce：確認鏈和發送者，比對已確認與待處理 nonce 資料，然後替換原本想執行的交易，或以相同 nonce 的取消交易與其競爭。

取消並非協定層級的撤銷。它通常是一筆由該帳戶向自身發送的 0 ETH 轉帳，使用相同 nonce 與原交易競爭。哪筆有效交易先被納入區塊，哪筆就會生效；已確認的交易無法用這種方式取消。

此流程適用於一般 EVM EOA 交易。智慧帳戶或帳戶抽象操作可能採用合約定義的 nonce 規則，而 UTXO 網路使用另一種交易模型。

nonce 缺口為何會阻塞佇列

EOA 的 nonce 是依序遞增的計數器。同一 nonce 只能執行一筆交易，而且帳戶不能先執行 nonce 26 再執行 nonce 25。因此，節點會把目前可執行的交易與留待未來執行的高 nonce 交易分開。

交易佇列並不是一個全域且權威的記憶體池。每個 RPC 節點看到並保留的待處理交易子集都可能不同。一筆交易可能出現在錢包中但不在區塊瀏覽器中，也可能透過一個 RPC 可見而透過另一個 RPC 不可見。這可能表示交易從未廣播、已被某個節點從交易池捨棄，或尚未傳播到所查詢的服務。

以 latest 呼叫 eth_getTransactionCount 會傳回最新區塊狀態中的交易計數；對 EOA 而言，可將其理解為已確認交易之後的下一個 nonce。以 pending 呼叫同一方法，則是在查詢單一節點的待處理狀態視圖。兩者不同表示該節點知道一些待處理交易，但不能證明所有公共節點也知道這些交易。

簽名前先診斷

  1. 停止所有裝置和應用程式從受影響地址繼續發送交易。記錄網路、chain ID、發送者地址、交易雜湊、nonce、接收者、金額、calldata、gas limit 和費用欄位。
  2. 確認錢包、區塊瀏覽器和 RPC 指向同一條鏈和同一發送者。nonce 屬於特定鏈上的帳戶，而不屬於某個錢包安裝實例。
  3. 分別用 latest 和 pending 查詢 eth_getTransactionCount，最好使用兩個獨立 RPC 供應商。將結果分歧視為記憶體池視圖不同的證據，而不是鏈上狀態不一致的證明。
  4. 依 nonce 檢查發送者的交易。如有條件，可用節點的交易池 API 區分可執行的 pending 項目與未來的 queued 項目。公共 RPC 供應商通常會停用這個非標準 API。
  5. 從 latest 值開始，找出第一個沒有已確認交易的 nonce。判斷該 nonce 上的已知交易仍然可見、已被捨棄，還是只在本機建立過。

不要只根據錢包的狀態標籤採取行動。正確鏈上的已確認 nonce、交易收據和區塊收錄情況才是決定性證據。

替換或取消第一個未解決 nonce

若要保留原操作：使用錢包的加速功能，或重新廣播一筆發送者、nonce、接收者、金額和 calldata 均相同，但費用具有競爭力的交易。簽名前檢查每個欄位；變更 payload 會使其成為另一項操作。

若要放棄原操作：在原交易尚未確認時，從該地址向自身發送 0 ETH，使用相同 nonce 和具有競爭力的費用。這只能嘗試讓自轉帳勝出。原交易仍可能先確認，因此在替換交易取得收據且原交易仍未確認之前，絕不能假定取消已成功。

節點是否接納替換交易取決於自身策略，並不存在通用的調升百分比。對 EIP-1559 交易，maxPriorityFeePerGas 和 maxFeePerGas 可能都需要提高，而且 maxFeePerGas 必須在目前 base fee 下仍可用。錢包估算和客戶端規則並不相同；出現 replacement transaction underpriced 錯誤，表示接收節點依目前策略沒有接受替換交易。

最低 nonce 確認後，重新檢查收據、latest、餘額以及每一筆較高 nonce 的交易。排隊交易可能立即變得可執行，而被所有相關節點捨棄的交易可能需要審慎地重新廣播。切勿盲目重發：應先確認先前的副本沒有被納入區塊。

範例

某地址的交易已確認至 nonce 24，因此 latest 為 25。一個 RPC 回報 pending 為 25，而錢包將 nonce 26 和 nonce 27 列為排隊。所有供應商都找不到 nonce 25 的已廣播交易。

帳戶擁有者先核對正確的鏈、發送者和已記錄的 payload。如果 nonce 25 原本有一筆想執行的交易，就用目前費用重建並廣播該操作，nonce 仍設為 25。如果沒有想執行的操作，則可以在 nonce 25 提交一筆 0 ETH 自轉帳。只提高 nonce 27 的費用無法填補缺口。

nonce 25 被納入區塊後，擁有者先檢查其收據，再處理 nonce 26 或 nonce 27。隨後逐筆審查這兩筆交易，因為其中任何一筆都可能已被捨棄，也可能在缺口關閉後迅速執行。

風險與停止條件

  • 替換交易可能與原交易競速。在鏈上證據顯示結果之前，應假定原接收者、金額和合約呼叫仍可能執行。
  • 在可信顯示裝置上確認完整的發送者地址、chain ID、nonce 和 calldata。惡意軟體或不可信的「復原」網站可能偷換成轉帳或授權。
  • 保留足夠的原生幣支付替換費用。被納入區塊的交易會收取 gas，即使合約呼叫隨後還原也是如此。
  • 復原 nonce 缺口不需要透露助記詞或私鑰。合法的 RPC、區塊瀏覽器或支援人員都不需要這些資訊。
  • 如果地址已經外洩，反覆公開廣播替換交易可能演變為與攻擊者的費用競賽。停止使用受感染裝置，依事件應變方案處理，不要臨時不斷加價。
  • 如果 RPC 供應商結果不一致、原接收者未知、無法重建 payload，或涉及大額合約互動，應暫停並在簽名前尋求專家協助。

對於跨裝置或自動簽署器的重複使用，應為每個帳戶和鏈只設定一個 nonce 分配器，序列化簽署，持久記錄預留 nonce 與雜湊，並同時對照已確認狀態和廣播節點的待處理池進行核對。僅重設錢包的本機活動記錄不會改變鏈上狀態或其他節點的記憶體池。

常見誤解

  • 「提高 nonce 27 的費用就能跳過 nonce 25。」 只有在較早 nonce 可執行後，這才可能提高優先順序；它不能修復缺口。
  • 「找不到就表示已取消。」 一個節點可能已捨棄交易，但另一個節點、區塊建構者或交易對手仍可能持有它。已簽署交易可以再次廣播。
  • 「0 ETH 自轉帳會撤銷原交易。」 它只是在相同 nonce 上競爭，原交易確認後便不起作用。
  • 「pending 是全網最終答案。」 它只是被查詢節點的待處理狀態視圖，不同供應商可能給出不同結果。

相關主題

來源

導覽

搜尋知識庫...