跳到正文
Financial Context Wiki

錢包中的 Calldata 解碼

以核驗為優先，系統說明交易呼叫資料、ABI 字組與偏移量、選擇器碰撞、代理、批次呼叫、授權、型別化資料許可、模擬與交易後核對。

更新於

僅供教育參考，不構成投資、法律或資安建議。解碼與模擬可減少歧義，但不能保證授權、執行、資產安全或最終性。

直接答案

Calldata 是作為輸入傳給以太坊頂層交易或內部訊息呼叫的不可變位元組字串。一般 Solidity 函式呼叫以一個 4-byte 選擇器開頭，後接 ABI 編碼參數，但 calldata 並非自我描述格式：對不同的執行期程式碼、代理實作或結構描述而言，同一組位元組可能代表不同含義。後備函式、原始組合語言及非 Solidity 協定也完全不必遵循一般函式 ABI。

因此，錢包顯示的資訊不應止於候選函式名稱。穩妥的檢視應把這些位元組與 chainId、特定區塊、from、to、原生資產 value、執行期 codeHash、目前實作合約和可信 ABI 綁定；嚴格解碼每一層巢狀呼叫；區分鏈上 calldata 與 EIP-712 簽章；在明確的狀態下模擬；並於交易納入區塊後核對實際回執與狀態變化。

Calldata 解碼
0 / 5
0 項已核查; 5 項仍未解決

完成核查不代表資產、交易或系統已經安全。

運作機制

  1. 固定簽署信封與觀察時點：chainId、區塊號碼與區塊雜湊、from、to、原生資產 value、輸入位元組、nonce 和費用欄位。保留錢包或 RPC 資料來源；來自另一條鏈或另一時點的解碼結果並非同一項判斷。
  2. 解碼前先判定物件類型。交易、EIP-712 型別化資料請求、ERC-2612 許可、ERC-4337 UserOperation 和原始 personal-sign 訊息使用不同的域與結構描述；不能全數強行套用交易 ABI。
  3. 在固定區塊解析目標。讀取執行期位元組碼和 codeHash；識別適用的代理、信標或實作合約；記錄實作與管理員儲存槽；並取得與該確切程式碼版本相符的 ABI。選擇器登錄資料庫只能提供候選項，不能作為權威依據。
  4. 嚴格解碼。選擇器是標準函式簽章經 Keccak-256 雜湊後的前 4 bytes，不含回傳型別。靜態值占用 32-byte 字組；動態參數標頭保存相對於選擇器之後參數區起點的偏移量。遇到截斷資料、越界偏移量、不可能的長度、無效填補或無法解釋的尾隨位元組，應拒絕簽署。
  5. 遞迴展開 multicall、巢狀 calldata 和委派執行。逐項列明子呼叫的目標、原生資產價值、選擇器、參數、呼叫類型及任何 allowFailure 旗標。使用 delegatecall 時，實作合約程式碼在呼叫方的位址、餘額與儲存空間脈絡中執行，同時保留 msg.sender 和 msg.value。
  6. 分別建立權限帳本與價值帳本，再進行模擬。記錄收款方、spender、NFT 操作員、代幣原始單位、decimals、截止時間、滑價界限與原生資產價值。使用確切區塊、傳送方與價值進行模擬，但應將結果視為條件式快照，因為狀態、價格、時間、程式碼和交易排序都可能改變。
  7. 簽署前確認每個重大欄位。納入區塊後檢查回執狀態、日誌、可用的呼叫追蹤，以及餘額、授權額度和操作員狀態變化；區分已捕捉的子呼叫失敗與頂層呼叫成功；即使交易回復也要計入 gas；等待所需最終性；若失敗原因無法解釋，應停止操作而非盲目重新簽署。

計算範例

  • 靜態 ERC-20 轉帳。 transfer(address,uint256) 通常使用選擇器 0xa9059cbb。一個選擇器加兩個 ABI 字組共 4 + 2 * 32 = 68 bytes。原始數量 1,500,000 對於已獨立核實採用 6 decimals 的代幣顯示為 1.5 tokens。decimals 屬於外部合約中繼資料，並未編碼在這些參數中；選擇器本身也無法唯一識別合約或函式。
  • 動態位元組偏移量。 對於 f(address,bytes)，若載荷為 3-byte，由兩個字組成的參數標頭占 64 bytes。動態偏移量為 0x40，從參數區起點計量，不包含選擇器。參數尾端包含一個 32-byte 長度字組和一個 32-byte 填補資料字組，因此 calldata 總長為 4 + 64 + 32 + 32 = 132 bytes。若將偏移量誤當成從第零位元組起算，位置會向後錯四個位元組。
  • 批次呼叫中的價值處理取決於實作。 外層呼叫帶有 1.00 ETH；三個已解碼子呼叫明確要求 0.20 ETH、0.30 ETH 和 0.10 ETH，合計 0.60 ETH。剩餘 0.40 ETH 可能退回、留存、繼續轉送，或導致回復，取決於批次呼叫程式碼。若第三個子呼叫失敗且設定 allowFailure=true，先前的子呼叫可能仍然生效；原子式實作則可能回復全部操作。
  • 許可簽章並不是簽署時中繼者的 calldata。 一名持有 1,000 USDC 的所有人簽署額度為 300 USDC、nonce 為 41 的 ERC-2612 許可。簽章本身既不改變餘額，也不改變授權額度。中繼者成功提交後，nonce 變為 42，授權額度變為 300；spender 隨後使用 180，餘額為 820，剩餘授權額度為 120。中斷網站連線並不會撤銷這項權限。

風險

  • 依錯誤的鏈、分叉、區塊標籤或交易信封解碼。
  • 為偽造網域、目標位址或收款位址簽署。
  • 儘管可能發生碰撞，仍把 4-byte 選擇器視為唯一識別碼。
  • 使用猜測、過時或未正確驗證的 ABI。
  • 只相信原始碼已驗證標籤，卻未比對目前執行期 codeHash。
  • 漏掉檢視與執行之間發生的實作、信標或管理員升級。
  • 忽略代理合約自身函式與實作合約發生的選擇器衝突。
  • 忘記 delegatecall 會在呼叫方的儲存空間脈絡中寫入狀態。
  • 接受異常的動態偏移量、長度、填補或尾隨位元組。
  • 未展開隱藏目標、價值或權限的巢狀批次呼叫。
  • 在實作會捕捉或容許子呼叫失敗時仍假定呼叫具有原子性。
  • 因代幣參數看似無害而忽略頂層原生資產 value。
  • 使用錯誤的 decimals，或假定轉帳收費和變基代幣遵循標準 ERC-20 行為。
  • 授予無限 ERC-20 授權額度，或錯誤處理授權額度更新競態。
  • 忽略 NFT setApprovalForAll 涵蓋整個系列的權限範圍。
  • 把 EIP-712 型別化資料或 ERC-2612 許可誤當成交易 calldata。
  • 漏查 nonce、截止時間、驗證合約、鏈域或重播界限。
  • 在預言機、時間戳記、待處理狀態、MEV 或程式碼變化下仍把模擬視為穩定結果。
  • 把回執狀態、日誌或服務商呼叫追蹤當成完整的經濟狀態證明。
  • 透過已遭入侵的介面盲目重新簽署，或忽略納入區塊、重組與最終性風險。

常見誤解

  • 函式選擇器可以唯一識別合約將執行的操作。
  • 已驗證的前端摘要與正在簽署的位元組及目前實作完全相同。
  • value=0 的交易無法移轉代幣、NFT 或已委託資產。
  • 模擬成功或回執成功可以證明安全性和預期經濟結果。
  • 中斷 dapp 連線會撤銷授權、許可和 NFT 操作員權限。

相關主題

來源

導覽

搜尋知識庫...