T1 · Blockchain 数据究竟是什么

一个现实问题

产品给你一个需求：某个地址一收到 USDC，就给用户推送通知。

看起来五分钟就能做完。于是你打开文档，开始纠结第一个问题：这个「收到」，我该去哪里读？

• 每隔几秒查一次这个地址的余额，变多了就推送？
• 监听 USDC 合约的 Transfer 事件？
• 把每个区块的交易都拉下来，逐笔解析？
• 直接用第三方 API，省事？

四种做法都能做出一个 demo，但它们在真实世界里的表现差异巨大：有的会漏消息，有的会重复推送，有的会在链重组时推送一条不存在的转账。

选错的代价不是性能，是正确性。要选对，先得搞清楚：链上到底存了什么。

思想实验

把一条链想成两样东西，而不是一样。

第一样：一本只能追加的流水账。

每隔一段时间产生一个区块，区块里按顺序装着若干笔交易。写下去就不能改，也不能插队。这本账只记录动作：谁调用了什么、带了什么参数、付了多少手续费。

第二样：一张由流水账推导出来的当前状态表。

每个账户现在有多少余额、每个合约的每个存储槽现在是什么值。这张表不是被「写」进链里的，它是从创世块开始把所有交易依次执行一遍得到的结果。

现在关键的问题来了：一笔交易执行时，改了哪些状态？

流水账里没有直接写。它只记了「调用了合约 A 的 transfer 函数，参数是地址 B 和数量 100」。至于这次调用最终改了多少个存储槽、有没有顺带触发别的合约，都要真的执行一遍才知道。

这就是为什么会有第三样东西：日志。合约在执行时主动喊一声「我刚刚做了一次转账，从 B 到 C，数量 100」。这一声被记录在交易回执里，专门给外部世界听。

你来决定

回到那个推送需求。你选哪一种？

观察结果

四个选项暴露出同一件事：你以为在读「链上数据」，其实在读它的某一层投影。

选哪一层，取决于你的业务能容忍什么。做一个余额展示，读状态就够；做资金对账，必须用追踪；做通知和索引，Event 是性价比最高的选择。

没有「最准确的那一层」，只有「和你的需求匹配的那一层」。

建立模型

把一条链的数据结构按层排开：

Block                       区块：一批交易的容器
 ├─ header                  头：父哈希、高度、时间戳、状态根
 └─ transactions[]          体：按顺序排列的交易
      └─ Transaction        一笔交易：from、to、value、data、nonce、gas
           └─ Receipt       回执：执行之后才产生
                ├─ status   成功还是失败
                ├─ gasUsed  实际消耗
                └─ logs[]   合约发出的事件
                     └─ Log  topics（可索引，便于过滤）+ data（内容）

State                       状态：由所有交易依次执行推导出来
 ├─ account balance         账户余额
 ├─ contract code           合约代码
 └─ contract storage        合约存储槽

四个要点，记住它们能让你少走很多弯路：

1. Receipt 在执行之后才存在。 交易被打包不等于成功，status 要单独看。前端把「已广播」当成「成功」是最常见的 bug（T14 会展开）。
2. Log 的 topics 是可索引的，data 不是。 这决定了你能按什么条件高效过滤：合约地址和 topics 可以，事件里的普通字段不行。
3. State 只有「现在」。 想查历史某个高度的状态，需要归档节点（T4 会讲）。这是一个常见的成本陷阱。
4. Event 不是状态。 合约可以发一个和实际状态完全不符的事件——这在攻击中被用过。真正要确认状态，得去读状态。

它叫什么

动手

curl -s -X POST <你的-RPC-地址> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

curl -s -X POST <你的-RPC-地址> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["latest",true]}'

curl -s -X POST <你的-RPC-地址> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["<交易哈希>"]}'

curl -s -X POST <你的-RPC-地址> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getLogs","params":[{
        "fromBlock":"0x...","toBlock":"0x...",
        "address":"<代币合约地址>",
        "topics":["<Transfer 事件签名的哈希>"]}]}'

AI Lab

第一步：
解释 Blockchain 上 State 和 Event 的区别，说明为什么两者可能不一致。

第二步：
给我三个具体场景，在这些场景下，只监听 Transfer 事件的索引器会得出错误结论。
每个场景说明：会漏掉什么、后果是什么、正确做法是什么。

真实案例

改一个变量

带走的问题

本章自测