鏈上原始交易解碼：拆解區塊鏈交易的輸入、輸出與腳本結構

打開任何一個區塊瀏覽器，輸入一筆交易哈希，通常會得到一張整理完備的表格：發送方、接收方、金額、手續費、確認數與狀態。這張表格是瀏覽器節點解析後的呈現，而鏈上真正被廣播、被節點驗證並打包進區塊的核心資料，本質上是一串十六進位原始字元（Raw Transaction Hex）。

這串原始位元組中並沒有直接標註「發送方」這個欄位，也沒有「帳戶餘額」的即時標籤。裡層結構僅由位元組長度前綴、引用的輸出索引、解鎖腳本、鎖定腳本與簽名組成。當區塊瀏覽器的解析邏輯與預期出現落差，或者面對多簽、合約內部調用與複雜找零機制時，掌握鏈上原始交易解碼的能力，便成為釐清資金真實流向與鏈上狀態的唯一確定手段。

區塊瀏覽器是經過二次加工的譯文，原始位元組才是底層共識認可的原文。

帳本模型差異：UTXO 與帳戶模型的解碼心智

同樣被稱為交易，比特幣與以太坊在底層位元組序列化上存在根本差異。理解帳本架構是解讀原始欄位的前提，能避免在比特幣交易中尋找發送方地址，或在以太坊交易中尋找找零輸出的概念錯位。

兩者在底層結構上的共通點在於：原始交易資料均不包含顯式的發送方（From）欄位。比特幣依靠輸入所引用的前序輸出腳本與當前提供的簽名驗證花費權限；以太坊則透過簽名參數反向推導出發送方公鑰與地址。瀏覽器介面呈現的來源地址，皆為解碼器運算後填入的視覺化資訊。

比特幣原始交易的位元組結構拆解

比特幣交易的序列化具有高度嚴謹的定長與長度前綴規則。包含隔離見證（SegWit）擴展的通用交易欄位排列順序如下：

在解析位元組時需注意兩個關鍵編碼規則：

• 小端序（Little-Endian）讀取：數值型欄位（如版本號、金額、LockTime）均採用低位元組在前的方式編碼。例如金額欄位為 8 位元組整數（單位為 Satoshi）。同時，輸入中的前序交易哈希在序列化資料中為小端序存放，而區塊瀏覽器顯示的 TxID 為大端序（需將位元組順序前後完全反轉）。
• 可變整數（CompactSize / VarInt）：長度編碼並非固定寬度。小於 253 時佔 1 位元組；等於 0xfd 時後接 2 位元組；等於 0xfe 時後接 4 位元組；等於 0xff 時後接 8 位元組。解析時必須動態判斷步長。

交易輸入與輸出結構剖析

在 UTXO 模型中，輸入（TxIn）負責引導並消耗既有資產，輸出（TxOut）負責鎖定並分配新資產。

交易輸入（TxIn）的五大組成

每個輸入項目在序列化資料中由五個部分組成：

1. Previous TxID（32 位元組）：被引用的前序交易雜湊（小端序存放）。
2. Previous Output Index（4 位元組）：前序交易中的輸出索引號（vout，從 0 起算）。
3. Script Length（VarInt）：解鎖腳本（scriptSig）的長度。
4. ScriptSig（可變長度）：提供解鎖所需的簽名與公鑰等數據（原生 SegWit 交易此處長度為 0x00）。
5. Sequence（4 位元組）：交易序號。

Sequence 欄位在不同條件下具備多重功能：當值小於 0xfffffffe 時，代表支援 BIP125 手續費替代機制（Opt-in RBF）；當交易版本 nVersion >= 2 且 Sequence 最高位（bit 31）為 0 時，此欄位會被解析為 BIP68 相對時間鎖；若所有輸入的 Sequence 均為 0xffffffff，交易直接定稿，LockTime 將不再施加約束。

交易輸出（TxOut）與腳本模板

每個輸出由兩部分構成：8 位元組的金額（Value，以 Satoshi 為單位的小端序）以及帶長度前綴的鎖定腳本（scriptPubKey）。常見的腳本標準特徵如下：

簽名雜湊範圍：SIGHASH 標誌

比特幣交易簽名並非直接對全部原始資料進行雜湊，而是依據簽名末尾的 SIGHASH 標誌 決定簽名涵蓋的資料範圍：

• 0x01 (SIGHASH_ALL)：簽名覆蓋所有輸入與所有輸出，最常見且具備最高防篡改性。
• 0x02 (SIGHASH_NONE)：簽名覆蓋所有輸入，但不覆蓋任何輸出，允許第三方修改收款對象。
• 0x03 (SIGHASH_SINGLE)：僅覆蓋所有輸入以及與該輸入相同索引號的單一輸出。
• 0x81 (ALL | ANYONECANPAY)：僅覆蓋當前輸入與所有輸出，允許其他人追加輸入組合。

以太坊型別化交易與 Calldata 解析

以太坊在經歷演進後，依據 EIP-2718 標準確立了型別化交易（Envelope Transaction）體系。在序列化位元組的最前端，單一標記位元組決定了後續 RLP 的編碼邏輯：0x01 代表 EIP-2930 存取清單交易，0x02 代表 EIP-1559 費用市場交易，0x03 代表 EIP-4844 Blob 攜帶交易。

以 EIP-1559 交易為例，其封裝欄位包含：chainId、nonce、maxPriorityFeePerGas、maxFeePerGas、gasLimit、to、value、data、accessList、以及簽名欄位（yParity, r, s）。在早期 Legacy 交易中，v 值僅代表恢復識別碼（27 或 28）；在 EIP-155 實施後，v 的計算納入了 chainId，以防止跨鏈重放攻擊。

Calldata 與事件日誌的解讀差異

當交易 to 指向智慧合約且 value 為 0 時，核心意圖完全由 data 欄位承載：

• 函數選擇器（Function Selector）：Calldata 前 4 位元組，為函數簽名 Keccak-256 雜湊的前 4 位元組。例如 0xa9059cbb 對應 transfer(address,uint256)。
• 參數列表：自第 5 位元組起，每 32 位元組為一個單位對齊編碼（ABI Encoding）。
• 事件日誌（Event Logs）結構：依據 EIP-20 規範，Transfer 事件定義為 Transfer(address indexed from, address indexed to, uint256 value)。在解碼收據（Receipt）時，topics[0] 為事件簽名哈希，topics[1] 為發送方地址（from），topics[2] 為接收方地址（to），而轉帳金額 value 屬於未索引欄位，存放於 Log 的 data 區塊中。

標準解碼操作流程與審計要點

1. 獲取完整原始資料：透過節點 RPC（如 Bitcoin Core 的 getrawtransaction，查詢歷史交易需節點開啟 txindex=1 或傳入所屬區塊哈希；以太坊透過 eth_getRawTransactionByHash）取得未經修剪的 Hex 字串。
2. 識別協議與交易型別：比特幣檢查第 5、6 位元組是否為 0x0001 判定是否啟用 SegWit 格式；以太坊讀取首位元組判斷 EIP-2718 型別。
3. 游標步進解析位元組：依序解析版本號、輸入長度、輸入清單、輸出長度、輸出清單、見證資料（若有）與 LockTime。嚴格按照 CompactSize 返回的偏移量推進游標。
4. 回溯前序狀態：將 TxIn 中的交易哈希反轉為大端序，查詢前序輸出的腳本類型與鎖定金額，以校驗手續費（輸入總值 – 輸出總值）。
5. 驗證腳本與調用意圖：解析腳本操作碼與參數堆疊；以太坊則進一步提取 Calldata 與 Receipt 日誌，確認是否存在內部調用（Internal Transactions）引發的狀態變更。

常見問題（FAQ）