3. 节点与RPC接口：全节点、轻节点、归档节点区别；JSON-RPC协议详解

聊到链上数据监控，你首先得搞清楚数据从哪来。

说白了，就是怎么跟区块链节点打交道。节点类型选不对，RPC接口用不好，后面监控系统跑起来全是坑。我踩过不少，今天帮你捋清楚。

3.1 三种节点类型：全节点、轻节点、归档节点

区块链节点，本质上是运行了客户端软件的服务器。但不同节点，存的数据量、验证方式、资源消耗天差地别。

节点类型	存储内容	验证能力	磁盘占用	典型用途
全节点	完整区块头 + 当前状态	独立验证所有交易	几百GB ~ 1TB+	日常交易、轻量查询
轻节点	仅区块头	依赖全节点验证	几MB	钱包、移动端
归档节点	完整区块头 + 所有历史状态	可查询任意历史状态	几TB ~ 十几TB	数据分析、审计、回溯

3.1.1 全节点

全节点是区块链网络的「中坚力量」。它下载并验证每个区块的每笔交易，维护当前最新的世界状态。

我个人习惯，在搭建生产级监控系统时，至少跑一个自己的全节点。为什么？因为第三方RPC服务商可能有速率限制，关键时刻掉链子，你监控系统就瞎了。

优点：数据完整、验证独立、安全可靠。

缺点：磁盘占用大，同步时间长（以太坊主网全节点首次同步可能要几天）。

3.1.2 轻节点

轻节点只下载区块头，不下载完整交易数据。它通过向全节点请求「默克尔证明」来验证交易。

你想想看，手机钱包不可能存几百GB数据吧？轻节点就是为这种场景设计的。

优点：资源占用极小，启动快。

缺点：依赖全节点，安全性稍弱，不适合高频数据查询。

嗯，这里要注意：轻节点不适合做监控系统的数据源。因为每次查询都要向全节点发起请求，延迟高、不稳定。

3.1.3 归档节点

归档节点是全节点的「超级版」。它不仅保存当前状态，还保存了所有历史状态——每个账户在任意区块高度的余额、每笔交易的完整上下文。

为什么需要它？举个例子：你想查询某个地址在一年前的ETH余额。全节点只能告诉你「当前余额」，归档节点才能告诉你「历史余额」。

我在做链上数据分析项目时，必须跑归档节点。没有它，很多回溯分析根本做不了。

3.2 JSON-RPC协议详解

节点跑起来了，怎么跟它交互？

区块链节点普遍暴露JSON-RPC接口。说白了，就是通过HTTP或WebSocket发送JSON格式的请求，节点返回JSON格式的响应。

3.2.1 协议基础

JSON-RPC 2.0规范很简单。一个请求包含三个字段：

• jsonrpc：固定为"2.0"
• method：要调用的方法名
• params：参数数组或对象
• id：请求标识，用于匹配响应

一个典型的以太坊JSON-RPC请求长这样：

// 请求：查询最新区块号
{
  "jsonrpc": "2.0",
  "method": "eth_blockNumber",
  "params": [],
  "id": 1
}

// 响应
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x10d4f2a"  // 十六进制区块号
}

3.2.2 常用方法分类

以太坊JSON-RPC方法很多，我按用途给你分个类：

类别	方法名	用途
链信息	eth_blockNumber, eth_chainId, net_version	获取链状态
账户查询	eth_getBalance, eth_getTransactionCount	查询账户余额、nonce
交易相关	eth_sendRawTransaction, eth_getTransactionReceipt	发送交易、查询交易回执
区块查询	eth_getBlockByNumber, eth_getBlockByHash	获取区块数据
日志/事件	eth_getLogs, eth_newFilter	监听合约事件
执行调用	eth_call, eth_estimateGas	模拟交易、估算Gas

3.2.3 核心方法详解

eth_getLogs——监控系统的核心方法

做链上监控，90%的时间都在跟eth_getLogs打交道。它用来查询合约触发的事件日志。

// 查询USDT转账事件（Transfer）
{
  "jsonrpc": "2.0",
  "method": "eth_getLogs",
  "params": [{
    "address": "0xdAC17F958D2ee523a2206206994597C13D831ec7",
    "fromBlock": "0x10d4f00",
    "toBlock": "0x10d4f2a",
    "topics": [
      "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"
    ]
  }],
  "id": 1
}

这里topics是事件签名的Keccak哈希。第一个topic通常是事件签名，后面的是索引参数。

eth_call——模拟链上查询

有时候你不想等事件，想直接查合约的当前状态。比如查某个地址在Uniswap池子里的流动性。

// 调用ERC20的balanceOf方法
{
  "jsonrpc": "2.0",
  "method": "eth_call",
  "params": [{
    "to": "0xdAC17F958D2ee523a2206206994597C13D831ec7",
    "data": "0x70a08231000000000000000000000000xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
  }, "latest"],
  "id": 1
}

data字段是方法选择器（4字节）加上参数ABI编码后的结果。嗯，这里要提醒你：eth_call不消耗Gas，但节点有速率限制。

3.2.4 WebSocket vs HTTP

监控系统需要实时性。HTTP是请求-响应模式，你得轮询。WebSocket是订阅-推送模式，节点主动通知你。

特性	HTTP	WebSocket
通信模式	请求-响应	全双工
实时性	需轮询，有延迟	即时推送
资源消耗	高（频繁轮询）	低（长连接）
典型方法	eth_getLogs	eth_subscribe

我个人建议：监控系统用WebSocket订阅新区块和待处理交易，用HTTP做历史数据回溯查询。两者结合，效率最高。

3.3 节点选择与RPC配置建议

总结一下我的建议：

• 监控系统数据源：跑自己的全节点，用WebSocket订阅实时数据
• 历史数据回溯：归档节点 + HTTP的eth_getLogs，分批查询
• 轻节点：别用在监控上，延迟和可靠性都不够
• RPC限流：自建节点也要注意，单IP请求量过大可能被节点自身限流

我曾经帮一个项目方排查监控延迟问题，最后发现是他们用的公共RPC节点，每秒请求量超过阈值，被悄悄降级了。换成自建节点后，延迟从分钟级降到秒级。

嗯，节点和RPC这块，说白了就是选对工具、配好参数。后面章节我们会具体讲怎么搭建节点、怎么封装RPC客户端，到时候再细聊。

---