Ethereum 網路核對：ERC20、0x 地址與 ETH Gas

ERC20 是代幣規格，Ethereum 才是網路

在轉帳介面裡，「ERC20」常被當作 Ethereum 主網的簡稱，但技術上它描述的是代幣合約遵循的介面。真正決定交易寫到哪本帳本的是 chain。接收端如果只支援 Ethereum，就不能因為 BSC 也有 0x 地址而改走 BSC。

一筆代幣轉帳至少涉及發送帳戶、代幣合約、接收地址、數量、nonce 和 Gas 參數。錢包畫面可能只顯示「向某地址發送 100 USDT」，實際簽署的卻是對 USDT 合約的函式呼叫。確認頁上的合約與 chain 因此比代幣圖示更重要。

0x 地址能檢查什麼

Ethereum 地址是 20 bytes，通常顯示成 0x 加 40 個十六進位字元。EIP-55 用大小寫混合提供 checksum，能協助發現部分輸入錯誤，但全小寫地址在部分工具中仍可能被接受。格式正確不代表地址活躍、有餘額或屬於預期收款人。

更重要的是，Ethereum 與多條 EVM 網路能從同一組金鑰導出相同外觀的地址。地址相同只代表公鑰導出結果相容，不代表資產跨鏈同步，也不代表託管平台監控每條 EVM 鏈。

發送前的合理順序是：

1. 在接收端確認網路完整名稱，而非只看 0x。
2. 核對代幣合約；同一符號可以對應不同合約。
3. 從可信通道取得地址並核對前後多個字元。
4. 讓錢包顯示 chain、合約、預估 Gas 與總支出。
5. 新路徑先做可承受的小額測試。

Gas 為何用 ETH 支付

Ethereum 以 Gas 衡量交易執行所需的計算量，再由 Gas 使用量與費率形成費用。即使你轉的是 ERC20 USDT，執行交易的仍是 Ethereum，因此通常要由帳戶以 ETH 支付費用。USDT 餘額不會自動轉成 ETH 來付 Gas。

錢包常顯示預估最大費用，而最終收費要看實際使用的 Gas 與納入區塊時的費率。不要把預估上限直接當作一定扣除的金額，也不要把低 Gas limit 與低費率混為一談：前者可能讓執行時可用 Gas 不足，後者可能降低交易被優先納入的機會。

Pending 與 Reverted 是兩種不同問題

pending 通常表示交易尚未形成已納入區塊的 receipt。常見檢查包括：交易是否廣播、nonce 是否接續、較早 nonce 的交易是否卡住，以及費率是否與目前區塊條件相差太大。

reverted 則表示交易已被區塊收錄，但 EVM 執行回滾。資產狀態可能沒有按預期改變，已消耗的計算成本卻仍須支付。此時要查 receipt 的 status、實際呼叫的合約、輸入資料與錢包或應用顯示的錯誤原因；反覆用相同參數重送通常只會再次失敗。

狀態	鏈上位置	優先檢查
查無 TxID	可能未廣播或網路選錯	chain、完整 TxID、錢包廣播紀錄
Pending	候選交易尚未穩定入塊	nonce、較早交易、費率
Success	receipt 顯示成功	代幣事件、地址、接收端確認門檻
Reverted	已入塊但執行回滾	receipt status、合約與錯誤原因

鏈上成功後仍未入帳

如果 receipt 成功且代幣事件顯示正確地址與數量，下一層是接收服務。核對對方是否支援該合約、是否達到確認門檻、是否低於最低入帳額，以及存款功能是否維護。對官方支援提供公開可查的 TxID、網路、資產和時間即可。

私鑰、助記詞、密碼、一次性驗證碼或 API key 一律不可交出。這些資料不能幫助平台查 receipt，只會把原本的到帳問題擴大成帳戶失竊風險。

Ethereum 交易由哪些欄位共同決定？

一筆一般交易包含發送者、接收者、數量、資料、nonce、Gas limit、費用參數與簽名。nonce 表示該帳戶交易的順序；同一帳戶的較高 nonce 通常不能越過尚未處理的較低 nonce。data 則可能觸發代幣合約或其他程式，不應因接收地址熟悉就忽略它。

EIP-1559 類型交易常見 maxFeePerGas 與 maxPriorityFeePerGas。實際費用取決於區塊 base fee、優先費和已使用的 Gas，不一定等於設定上限乘以 Gas limit。簽名前比較錢包估算、目前網路狀態與交易用途；陌生 DApp 要求極高上限時應先停下讀取操作內容。

ETH 轉帳與 ERC20 轉帳為何要分開看？

ETH 是 Ethereum 的原生資產，ERC20 代幣則由合約記錄餘額。ERC20 轉帳通常是向代幣合約呼叫方法，真正的接收人和數量出現在輸入資料與 Transfer 事件中。區塊瀏覽器頂部的 to 可能是合約地址，原生 value 也可能為零。

因此核對代幣付款時，要查看 token transfer、合約地址、事件中的 from/to 與小數位。只見交易 success，卻沒有預期 Transfer 事件，不能假設代幣已到達。假代幣也能使用相同符號，合約仍要向發行方正式來源確認。

Nonce 卡住時怎麼分析？

先列出同一發送地址近期 pending 交易，找出最小缺口 nonce。後續交易即使費用較高，也可能等待前一筆完成。若錢包支援 speed up，通常是以相同 nonce 建立費用更高、內容相同或等價的替代交易；cancel 則常以相同 nonce 向自己發送零值交易競爭，兩者都不是鏈上撤回保證。

現象	可能原因	核對項目
多筆一起 pending	低 nonce 交易阻塞	帳戶 pending nonce 序列
Hash 後來查不到	節點移除或被替換	同 nonce 的其他 hash
Success 但 DApp 顯示失敗	前端未刷新或業務條件未完成	receipt、logs、DApp 狀態
Reverted	合約執行拒絕	receipt 與模擬錯誤

不要同時在多個錢包隨機修改 nonce，否則更難辨認哪筆會被打包。每次替換保存新舊 hash 與費用參數。

一筆 Ethereum 交易由哪些欄位共同決定？

至少要讀發送地址、to、nonce、value、data、chain ID、Gas limit 與費用參數。ETH 轉帳通常把數量放在 value；ERC20 轉帳則多半呼叫 token 合約，接收地址與數量編碼在 data，外層 to 是合約。只看外層 to 會誤以為 token 送給合約，必須再看解碼後函式與 Transfer log。

Chain ID 防止同一簽名在不相容網路重播，也用來確認目前究竟是 Ethereum 主網還是另一條 EVM 鏈。0x 地址和 hash 外觀不能單獨識別網路；從發送端設定、chain ID 與正確瀏覽器交叉證明。

ETH、ERC20 與 approval 的資產變化怎麼分開？

ETH 轉帳會改變原生餘額；ERC20 transfer 會在 token 合約中產生事件；approval 只改變 spender 可使用的額度。三種交易都可能顯示 success，但對收款結果的意義不同。看到 approval 成功而平台未入帳，不應要求平台查充值，因為 token 可能根本沒有轉出。

排錯時比較交易前後 ETH 餘額、token balance、allowance 與 Transfer log。若 swap 或 deposit reverted，先前獨立 approval 仍可能有效；不再使用時評估降低權限，但撤銷也必須在可信介面核對 spender 和 token。

Gas limit、Gas used 與費率有什麼差別？

Gas limit 是願意讓交易最多使用的計算量，Gas used 是實際執行消耗；費率決定每單位 Gas 的支付上限與優先小費。把 Gas limit 調高不會修正合約條件，也不代表一定支付整個上限。Reverted 交易可能在消耗一部分 Gas 後回滾狀態，因此 ETH 減少而 token 未移動。

估算失敗時讀 simulation 或錯誤原因，不要只增加 limit。若交易涉及陌生合約，先確認函式與資產方向；高額 limit 加上惡意 calldata 會放大損失，而不是提高成功率。

Nonce 卡住時應按什麼順序處理？

列出最早未確認 nonce，確認是否已廣播、是否能被目前錢包安全替換，再處理後續交易。Speed up 通常保留相同內容並提高競爭費率；cancel 通常用相同 nonce 向自己發一筆新交易。兩者都會建立新 hash，結果取決於哪個版本先被確認。

不要跳過 nonce 建立更多付款，也不要在多個錢包介面同時操作同一帳戶。保存每個候選 hash、nonce、輸出與費用，最後只把實際上鏈版本記入帳務。

合約呼叫前，模擬與介面預覽能提供什麼？

模擬可揭示當前狀態下的 revert、預期 token 變化與部分內部呼叫；錢包預覽可提示 approval、資產轉出或高風險簽名。但它們不保證打包時狀態不變，也不能替使用者判斷陌生合約是否值得信任。把結果當作額外證據，不是安全承諾。

若介面描述與解碼資料不一致，停止簽名。公開查詢與 ABI 解碼不需要助記詞；任何要求先連接錢包才能「看懂交易」的未知網站都應避免。

平台充值成功前要跨過哪些獨立關卡？

首先是鏈上交易成功，其次是正確 token 合約把資產轉到平台控制地址，再來是達到平台確認門檻、通過最低額與地址映射，最後才是帳戶 credit。任一層出錯都可能呈現「鏈上成功、平台未入帳」。工單要提供 TxID、網路、合約、接收地址、數量、確認數與充值頁，讓平台能定位具體關卡。

如果選錯 EVM 網路，即使地址字串相同，也只有平台能判斷它是否控制另一條鏈的對應地址。使用者不能匯入平台私鑰，也不應向第三方支付找回費。

硬體錢包與地址簿怎樣降低人為錯誤？

在硬體裝置螢幕核對目的地址、金額與必要合約欄位，避免電腦剪貼簿被替換。常用地址可先小額驗證後放入有網路標籤的地址簿，但每次仍要確認 chain 和完整地址；地址簿不能替代平台當次充值頁。

大額操作可分成測試與主交易，等待測試在接收端真正入帳後重新取得收款資料。這個流程成本略高，卻比只看 0x 前綴或交易歷史尾碼可靠得多。

Event log、內部呼叫與外層交易如何一起閱讀？

外層 transaction 說明誰簽名、呼叫哪個地址與附帶多少 ETH；內部呼叫顯示合約執行路徑；event log 則由合約記錄 Transfer、Approval 等事件。核對 token 付款時，三者要連在一起讀。外層 value 為零不代表沒有 token 移動，外層 to 是合約也不代表 token 永久送進合約。

瀏覽器的解碼依賴 ABI 和標籤，未知合約可能顯示不完整。以原始地址、topics、data 與餘額變化交叉確認，不要只看網站給的友善名稱。

Proxy 合約與實作合約為何容易讓使用者看錯？

許多應用讓使用者與 proxy 地址互動，程式邏輯位於 implementation。核對安全性時要確認官方文件列出的入口、目前實作與管理權限；不要因瀏覽器顯示另一個實作地址就任意改送 token 的目的地。Token 直接轉給合約能否取回，取決於合約是否有對應函式與管理能力。

升級權限、暫停功能與多簽管理都是風險資訊，但不能單憑存在就斷言惡意。使用者應理解自己簽署的函式和資產變化，未知時停止。

ENS 或通訊錄名稱在簽名前還要核對什麼？

名稱解析方便閱讀，最後簽名仍要顯示解析出的 chain 與完整地址。名稱記錄可能更新，錢包也可能在不同網路解析不同資訊；不能只看熟悉名稱就忽略裝置螢幕。大額付款可先用可信瀏覽器獨立解析，再與錢包預覽比較。

地址簿同樣需要網路標籤和最後驗證日期。若收款人改地址，透過第二個已驗證渠道確認，不從交易歷史中直接挑相似地址。

交易完成後如何核對實際 ETH 與 token 差額？

以區塊前後餘額、receipt、Gas used、effective gas price 與 Transfer log 重建差額。ETH 減少可能同時包含轉帳 value 和 Gas；token 變化則由合約狀態與事件解釋。錢包法幣總值會受價格波動影響，不適合用來核對交易當時到底移動多少資產。

若 DApp 同時執行多步，逐一查看涉及的 token、內部呼叫和退款，不用最終收到的一個資產數字推測全部路徑。保存原始 TxID 與解碼日期，之後 ABI 或介面標籤改變時仍能回到原資料。

緊急事件中先移資產還是先撤銷授權？

這取決於仍可控制的帳戶、可疑授權範圍、攻擊是否持續和可用 Gas。不要照固定清單在受感染裝置反覆簽名；先用乾淨環境與可信錢包核對地址、spender、token 和 permission。若私鑰可能已暴露，單純撤銷一個 allowance 不能恢復整個帳戶安全。

保存可疑交易與授權證據，必要時尋求錢包或合約官方支援。任何救援流程都不要求把 seed 傳給第三方；能夠簽名的人本身就擁有移動資產的能力。