2. 以太坊虚拟机(EVM)原理：账户模型、Gas机制与交易回执解析
说实话，很多刚入行的朋友问我：「链上数据到底怎么追踪？」我通常会反问一句：「你搞清楚EVM怎么跑的吗？」
嗯，这个问题问到了根上。EVM是以太坊的「心脏」，不理解它，你看到的链上数据就是一堆乱码。今天我就带你把这颗「心脏」拆开看看。
2.1 账户模型：EOA vs 合约账户
以太坊的账户模型，说白了就两种：外部账户（EOA）和合约账户。我刚开始做链上分析时，经常把这两者搞混，后来踩了不少坑才明白它们的本质区别。
2.1.1 外部账户（EOA）
EOA就是由私钥控制的账户。你用的MetaMask钱包，生成的每个地址都是EOA。它的特点很鲜明：
- 有私钥——谁有私钥谁就能控制它
- 可以发起交易——只有EOA能主动「说话」
- 存储ETH余额——但没法存复杂数据
我个人习惯把EOA比作「人」——有钥匙（私钥），能开门（发起交易），但记性不好（只能存余额）。
2.1.2 合约账户
合约账户就不一样了。它没有私钥，完全由代码控制。你想想看，一个没有钥匙的「保险箱」，别人往里面存钱，它自己按规则往外吐钱——这就是合约账户。
合约账户的核心特征：
- 无私钥——代码即法律
- 由部署交易创建——部署时生成地址
- 可以存储状态——余额、映射、数组等
- 被EOA或其他合约调用——不能主动发起交易
关键区别：EOA是「人」，合约是「机器人」。人主动做事，机器人被动响应。追踪资金流向时，你要特别关注「人」到「机器人」的交互点。
2.2 Gas机制详解
Gas，中文叫「燃料」。为什么需要它？因为EVM执行代码需要计算资源，你不能让矿工白干活。我在项目中遇到过好几次因为Gas估算不准导致交易失败的案例，嗯，学费交得有点贵。
2.2.1 Gas的组成
一笔交易的Gas消耗由两部分组成：
| 组成部分 | 说明 | 示例 |
|---|---|---|
| 基础费用（Base Fee） | 网络拥堵时自动调整 | EIP-1559引入，会被销毁 |
| 小费（Priority Fee） | 给矿工的额外激励 | 俗称「矿工小费」 |
| Gas Limit | 你愿意消耗的最大Gas量 | 简单转账21000，复杂合约几十万 |
实际交易费用 = Gas Used × (Base Fee + Priority Fee)。
举个例子：你转一笔USDT，Gas Used是50000，Base Fee是20 Gwei，Priority Fee是2 Gwei。那么总费用 = 50000 × (20+2) = 1,100,000 Gwei = 0.0011 ETH。
我的经验：追踪大额资金时，我通常会看Priority Fee。如果某笔交易给了异常高的小费，八成是急着抢跑——可能是套利、清算或者抢Mint。这种交易值得深挖。
2.2.2 Gas Limit的陷阱
我曾经犯过一个低级错误：给合约调用设了21000的Gas Limit。结果呢？交易直接revert了。为什么？因为21000只够普通转账，合约调用至少需要50000+。
Gas Limit设得太低，交易会失败，但Gas照扣不误。设得太高，多余的Gas会退还。所以我的建议是：
- 普通ETH转账：21000
- ERC-20转账：50000-80000
- 复杂合约交互：100000-300000
- DeFi聚合器：可能到500000+
2.3 交易回执（Receipt）解析
交易发出后，你拿到的不是「成功」或「失败」这么简单。交易回执里藏着大量信息。我每次做链上分析，第一件事就是解析Receipt。
2.3.1 Receipt的核心字段
一个标准的交易回执长这样：
{
"transactionHash": "0xabc...",
"transactionIndex": "0x1",
"blockNumber": "0x10d4f",
"from": "0x123...",
"to": "0x456...",
"cumulativeGasUsed": "0x5208",
"gasUsed": "0x5208",
"contractAddress": null,
"logs": [...],
"status": "0x1",
"logsBloom": "0x00..."
}重点看这几个：
- status：0x1成功，0x0失败。别只看这个，有时候status是1但实际逻辑没执行——嗯，我遇到过这种坑
- gasUsed：实际消耗的Gas。对比Gas Limit，能看出有没有浪费
- logs：事件日志。这是追踪资金流向的关键
- contractAddress：如果是合约创建交易，这里会显示新合约地址
2.3.2 事件日志（Logs）的妙用
Logs是EVM的「广播系统」。合约通过emit事件，把信息广播出去。比如ERC-20的Transfer事件：
event Transfer(address indexed from, address indexed to, uint256 value);解析这个事件，你就能知道：谁转了多少钱给谁。我追踪黑客资金时，就是靠这些事件日志一步步画出资金流向图的。
实战技巧：用Web3.py解析事件日志时，记得用event.processReceipt()方法。它会自动把indexed参数解码成地址，省去手动转换的麻烦。
2.3.3 实战：解析一笔USDT转账
假设你看到一笔交易，hash是0xabc...。用Web3.py解析：
from web3 import Web3
w3 = Web3(Web3.HTTPProvider('https://mainnet.infura.io/v3/YOUR_KEY'))
tx_hash = '0xabc...'
receipt = w3.eth.get_transaction_receipt(tx_hash)
# 解析Transfer事件
transfer_event = w3.eth.contract(
address='0xdAC17F958D2ee523a2206206994597C13D831ec7',
abi=USDT_ABI
).events.Transfer()
logs = transfer_event.process_receipt(receipt)
for log in logs:
print(f"From: {log['args']['from']}")
print(f"To: {log['args']['to']}")
print(f"Value: {log['args']['value'] / 10**6} USDT")注意：USDT的精度是6位小数，不是18位。很多新手在这里翻车，算出来的金额差了12个数量级。我刚开始也犯过这个错，后来养成了习惯：每次解析代币事件前，先查一下decimals。
2.4 知识体系总览
为了让你更直观地理解EVM的核心逻辑，我画了一张图：
这张图把EVM的核心逻辑串起来了：EOA发起交易，消耗Gas，合约执行逻辑，最终生成Receipt。你追踪资金流向时，就是沿着这条链路逆向分析——从Receipt的事件日志里，提取出转账信息，再结合Gas消耗判断交易行为。
我的建议：刚开始做链上分析时，别急着上复杂工具。先用Etherscan打开一笔交易，手动看Receipt的每个字段。看多了，你自然就能从一堆十六进制数据里嗅出异常来。
好了，EVM的账户模型、Gas机制和交易回执就讲到这里。这些是链上数据分析的「内功心法」，练好了，后面追踪资金流向时才能得心应手。