T4 · RPC 是什么

一个现实问题

本地跑得好好的 DApp，上线第三天开始出怪事。

• 有用户说打开页面余额是 0，刷新几次又对了。
• 有用户说交易记录少了几条，第二天又全了。
• 你自己怎么试都正常。

你去翻日志，看到一堆 429。再往下翻，看到几条超时。再往下，看到一次返回的区块高度比五分钟前那次还要小。

这时候你才意识到一件事：**你的代码从头到尾没有碰过任何一条链。**它碰的是一个 HTTP 端点——一个你没写过、没部署过、没监控过、出了问题也进不去看日志的服务。

那个端点后面是谁？它凭什么给你数据？它什么时候会不给？它给错了你怎么知道？

思想实验

假设你在做一个报表系统，数据来自一个只读的数据库副本。有人告诉你这个副本有五个特点：

1. **它会限速。**每秒超过若干次查询就拒绝你，而且不同查询的「重量」不一样——查一行和扫一千万行算的额度差几百倍。
2. **它可能落后。**主库写入之后，副本什么时候同步完没有保证。你连续查两次，第二次可能比第一次更旧，因为负载均衡把你分到了另一台机器。
3. 它可能没有历史。为了省磁盘，它只保留最近一段时间的数据。查更早的，它不是返回空，是报一个你看不懂的错。
4. **它可能返回假数据。**没有任何机制阻止它这么做。你收到的是一个 JSON，你无法从这个 JSON 本身判断它对不对。
5. **它不归你管。**它挂了，你只能等。

现在问自己一个问题：在这五个前提下，你还能做出一个可靠的报表系统吗？

能，但你的架构必须显式地处理这五件事：限速要有退避和排队；落后要有单调性校验；历史缺失要提前知道边界在哪；假数据要有交叉验证；不归你管要有备份来源。

这五件事，就是这一章的全部内容。

把「只读副本」换成「RPC 端点」，上面每一条都原样成立。差别只有一个：那个数据库至少是你们公司的，而这个端点不是。

你来决定

你要给一个即将上线的产品选 RPC 方案。

观察结果

四个选项的差异，可以收成五个维度：

五个维度里，只有「信任」这一条是无法用钱解决的。

其余四条都是取舍：多花钱买额度、多花钱买归档、多花人力自建。只有「我怎么知道这个 JSON 是真的」这件事，不管你付多少钱，答案都一样——你不知道，除非你自己验证。

这是理解 RPC 最重要的一句话：**用第三方 RPC，意味着你信任它返回的数据。**你的产品的去中心化程度，在接入那一刻就被这个端点封了顶。

建立模型

一次调用真正走过的路：

决定你产品上限的三个维度：

一、限速。不要按「每秒多少次请求」来理解，要按「计算量额度」来理解。一次读余额和一次扫描一百万个区块的日志，消耗的额度可能差几百倍。所以你的用量曲线不取决于用户数，取决于你调用了哪些方法。

优化的第一步永远是：把日志范围缩小、把批量查询合并、把不变的数据缓存住。T15 会讲缓存层。

**二、数据深度。**节点分三种：只保留最近状态的（大多数），保留全部区块但状态被裁剪过的，以及保留每一个历史高度完整状态的归档节点。

查一个很老高度的余额或存储，前两种会报错而不是返回空。这个错误信息通常长得完全不像「没有历史数据」，第一次见到的人一般会以为是自己参数写错了。

**三、一致性。**同一时刻，两个实例的最新高度可能不同；链末端还会重组。这意味着两件事：

• 同一个逻辑请求连着发两次，第二次可能读到更旧的状态。
• 你按「最新」读到的数据，可能在几秒后就不存在了。

处理方法是用明确的区块标签，而不是每次都用「最新」：

**一条实践规则：任何需要「跑两次结果一样」的逻辑，都必须把区块高度固定下来，而不是用 latest。**索引器尤其如此——用 latest 写出来的索引器是不可重放的，出了问题你连复现都做不到。

自有封装层该有的能力：

最后两条是把「多个后端」和「高可用」区分开的地方。只有前四条，你做的是负载均衡；加上后两条，你才是在处理不信任。

它叫什么

动手

for i in $(seq 1 10); do
  curl -s -o /dev/null -w '%{time_total}\n' -X POST <端点 A> \
    -H 'content-type: application/json' \
    -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'
done

curl -s -X POST <端点 A> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBalance",
       "params":["<任意活跃地址>","0x<一个很老的区块高度>"]}'

curl -s -X POST <端点 A> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getLogs","params":[{
        "fromBlock":"0x...","toBlock":"0x...",
        "address":"<一个活跃的代币合约地址>"}]}'

AI Lab

第一步：
写一个 RPC Provider 封装，要求：
支持多个后端端点、超时、失败重试加指数退避、
按方法路由（归档类方法走指定端点）、以及熔断。
用我指定的语言，不要用任何我没提到的第三方库。

第二步：
现在假设这个封装被用在一个需要重放的索引器里。
逐条指出你上面的实现会在哪些情况下返回「不一致但看起来正常」的结果。
对每一条给出修复方案。

真实案例

改一个变量

带走的问题

本章自测