區塊瀏覽器不是收據圖片：逐層閱讀交易與代幣事件

社交媒體常貼一張區塊瀏覽器截圖，圈出金額、地址或「Success」，再附上一個簡短結論。問題在於，瀏覽器頁面同時呈現網路狀態、交易封裝、程式呼叫、解析標籤與平台自製摘要。截圖可以保存當時畫面，卻不會自動證明圈選文字所暗示的因果關係。

閱讀公開交易的穩健順序是：先確認網路與識別碼，再看鏈上收錄及執行狀態，接著檢查原生資產與代幣層的狀態變化，最後才閱讀瀏覽器提供的名稱、標籤或人類可讀摘要。這不是轉帳操作教學，而是一套證據分層方法。

第一層：先固定網路、識別碼與頁面版本

交易 hash 或 signature 只在指定網路的狀態空間內有意義。記錄必須同時保存 chain／cluster、完整識別碼、瀏覽器網址、觀察時間與頁面狀態。只貼縮短字串，之後便無法排除不同網路、不同交易或被重新導向的頁面。

Etherscan 的公開說明將 transaction hash 描述為交易的唯一識別碼，可用來追蹤狀態。它同時列出 status、block、timestamp、from、to、value、fee、gas、nonce 與 input data 等欄位。這些欄位共同描述一筆 EVM 交易，但每一欄能支持的命題不同。

瀏覽器本身也有版本與解析層。名稱標籤、代幣圖示、方法名稱或「轉帳」摘要可能由平台資料庫和 ABI 解碼產生，並非全部直接儲存在鏈上。保存原始 hash 能讓其他人改用另一個節點或瀏覽器核對；只保存畫面標題則可能把後續更新的標籤誤當成交易當時已知資訊。

第二層：收錄、確認與執行成功是不同問題

EVM 交易頁的 block 表示交易被記錄在哪個區塊，confirmations 描述其後已有多少區塊。status 則回答執行是否成功。被收錄不等於每個內部操作都符合發送者原先意圖；交易失敗也不等於鏈上沒有留下紀錄或沒有消耗費用。

Etherscan 文件指出，失敗交易可能仍扣除 gas fee。這提醒讀者分開 value movement 與 execution cost。頁面 `Value` 是交易封裝中的原生資產值，`Transaction Fee` 則由 gas used 與 gas price 等資料形成；兩者不應合併成「轉出了多少」。代幣轉移還要查看事件與狀態變化，不能只看頂層 Value。

時間欄也需標明語意。區塊 timestamp 是鏈上區塊的時間資訊，瀏覽器顯示「幾分鐘前」是相對呈現，本站截圖時間只是何時看到頁面。三者可以互相補充，卻不能用截圖時間改寫交易發生時間。

第三層：from、to 與實際作用對象不要混為一談

EVM 頁面的 `From` 是發送地址，`To` 可以是接收地址或被呼叫的合約。若 `To` 是路由器合約，最終代幣接受者、資金池與被呼叫代幣可能出現在 input、internal calls 或 logs 中，而不在頂層 `To`。因此「To 等於某合約」不能單獨證明該合約最後取得所有資產。

`Input Data` 保存額外呼叫資料。當來源碼與 ABI 可用時，瀏覽器可能把它解碼成方法名稱和參數；沒有可靠 ABI 時，只能保存原始資料及未解碼狀態。人類可讀方法名稱是解碼結果，不是另一筆獨立鏈上證據，也不能因名稱看起來熟悉就忽略實際合約地址。

internal transaction 或 internal call 是執行期間的合約呼叫視圖，不是另一筆擁有獨立 hash 的外部交易。事件 log 則是合約執行時發出的結構化紀錄。兩者可協助重建路徑，但事件內容由合約邏輯產生；要判斷資產狀態，仍需核對正確合約、事件簽章、索引參數及交易是否成功。

第四層：代幣轉移要綁定合約與原始單位

瀏覽器把某個 log 顯示為 Token Transfer 時，至少要保存 token contract、from、to、raw amount、decimals 與顯示 amount。名稱與代號只是呈現資訊，完整合約才是 EVM 代幣身分。若 decimals 來源未確認，原始整數不能任意插入小數點。

一筆交易可能包含多個 token transfer、池內交換、費用轉移或包裝資產動作。只截取其中最大數字會切斷事件上下文。較可靠的事件表按 log index 排序，分列合約與方向，再標出哪些是瀏覽器解析、哪些已由原始 log 核對。

餘額變化與事件也不是永遠一對一的通用保證。事件是程式發出的紀錄，狀態是執行後儲存的結果；研究特定合約時需要了解其實作。本文不從一個 `Transfer` 標籤推導專案真偽、資金用途或經濟所有權。

Solana 先讀帳戶與指令，不套用 EVM 欄名

Solana 的核心文件把 account 描述為保存 lamports、data、owner、executable 等狀態的物件；program 本身處理 instruction，而可變資料存放在帳戶。交易訊息包含 account keys、recent blockhash 與 instructions，並由 signatures 授權。這個模型不應被硬套成單一 `From` 與 `To`。

Solana 的一條 instruction 可讀寫多個帳戶，並指定 program。交易還可能產生 inner instructions。研究者要按 instruction index 與 stack 層級理解哪個 program 被呼叫、哪些帳戶參與，而不是把 account keys 清單的第一個和最後一個直接命名為發送者及接收者。

SPL Token 文件又把 mint account 與 token account 分開。mint 定義代幣種類與 decimals、authority 等資料；token account 保存某 owner 對該 mint 的代幣狀態。瀏覽器顯示一串公開鍵時，應先辨認帳戶類型，否則可能把持有帳戶錯當代幣 mint。

用 getTransaction 核對 Solana 頁面摘要

Solana `getTransaction` 文件說明，查詢以 base-58 signature 為識別，會在指定 commitment 下回傳已確認交易；找不到或未在該條件下確認時可回傳 `null`。`null` 不是失敗交易的同義詞，也不能改寫成零筆活動，它只表示這次查詢條件沒有取得交易物件。

回應頂層包含 `blockTime`、`meta`、`slot`、`transaction` 與 `version`。`meta.err` 可用來觀察執行錯誤，`fee` 是費用，`preBalances` 與 `postBalances` 提供原生單位前後狀態；`preTokenBalances` 與 `postTokenBalances` 則可保存 mint、owner、program 與 token amount 等資料。研究時應保存原始整數與 decimals，不只抄 `uiAmount`。

`logMessages` 和 `innerInstructions` 可協助追蹤 program 呼叫，但它們需要與 instruction index、account keys 及 program ID 一起閱讀。某行 log 寫著 success，只能支持那個呼叫在該執行脈絡的狀態，不能跳過頂層 `meta.err` 或把它提升為整個專案的安全證明。

顯示金額要回到原始整數與精度

瀏覽器為方便閱讀，通常把鏈上的最小單位轉成人類可讀數字，再加入代號、小數分隔或近似美元值。這層格式化可以協助快速瀏覽，但研究記錄應同時保存 raw amount、decimals、顯示字串與換算來源。否則畫面上的 1.2 可能無法分辨是精確值、四捨五入值或縮寫值。

美元估值更不是交易原始欄位。它可能以頁面當前價格、交易時點估值或供應商自訂方法換算；若頁面沒有說明，就把估值時間與方法標為未知。不能由現在顯示的美元數倒推交易發生時一定具有同一市場價值。

前後餘額也要先核對帳戶集合。在 EVM 中，頂層原生資產變化可能受 fee 與 internal calls 影響；在 Solana 中，`preBalances` 和 `postBalances` 的索引要對應 account keys，token balances 還有 mint 與 account index。只取兩個最大數字相減，容易把不同帳戶或不同單位混在一起。

精度欄位缺失時，可靠輸出是原始值加上「無法格式化」，而不是猜一個常見 decimals。這種保守處理看來不夠漂亮，卻保留了之後取得正確 mint 或合約資料時重建顯示值的可能。

一張逐層證據卡

面對瀏覽器標成「成功」且列出多筆代幣轉移的事件，證據卡不重述「某人買了某幣」，而是分成五層：

1. 身分層：網路、完整 hash／signature、block／slot、觀察網址與時間。
2. 執行層：status 或 `meta.err`、費用、版本與確認條件。
3. 呼叫層：EVM 的 to／input／internal calls／logs，或 Solana 的 account keys／instructions／program IDs。
4. 資產層：完整 contract／mint、token account、raw amount、decimals、前後餘額與方向。
5. 解析層：瀏覽器標籤、方法名稱、圖示及其來源；無法核對的欄位標成 unresolved。

這張卡不會替匿名地址指定真實人物，不會由金額猜測意圖，也不會把成功執行翻譯成資產安全。它只保留公開鏈上資料能支持的事件範圍。

截圖與連結各自扮演什麼角色

真實公開頁面截圖適合保存某日看到的欄位配置、標籤與解析結果，但必須附來源 URL、截取時間、網路及完整識別碼。若畫面含與研究無關的地址，可依發布規則裁切，卻不能修改數值、狀態或製造不存在的介面。

可重現記錄還要保留文字化欄位，因為截圖不利於精確搜尋、比對完整字串或識別被截斷內容。反過來，只有 API 回應也可能缺少當時頁面的解析標籤。兩者並存時，應標清「鏈上欄位」與「瀏覽器呈現」，不讓一張圖替所有層背書。

最後，把未知留在原位。地址歸屬不明就寫不明，`null` 就保存 `null`，解析失敗就保存原始 input 或 data。區塊瀏覽器最有價值之處，是讓公開事件可以沿識別碼被重新核對；研究者的責任，是不讓易讀摘要越過證據本身的邊界。