BlockPI 日志查询报错：检查 Ethereum 合约、区块切片和 RU
链小知 · 进阶 · 核验 · 依官方文档整理
对照 eth_getLogs 的脱敏记录，用固定区块与合约过滤检查漏片、业务错误和大响应限制。
开始前准备
- 准备 Ethereum 的目标起止区块、完整合约地址、topics、已有请求/响应和端点类型；key 必须脱敏。
- 使用明确固定的目标范围，而非连续变化的 latest；没有成功返回的切片按未知处理。
1. 确认 Ethereum 主机与端点类型
对照既有 endpoint 的 network 与 HTTPS/私有或公共类型。官方 Best Practices 的 Ethereum 示例为 https://ethereum.blockpi.network/v1/rpc/<key>；Ethereum 方法页 curl 却写 arc 主机，不能照抄。私有端点按所选网络生成，公共不支持 WS；一次 eth_getLogs 查询也不等于 eth_newFilter 或订阅，HTTPS 的限制需按对应方法看。
检查结果：主机属于目标 Ethereum 环境，类型与方法一致，未复制 arc 或其他网络入口。
2. 固定区块边界与日志身份
检查 params 中的单个 filter：fromBlock/toBlock 用固定十六进制区块号，address 是发出日志的合约，不是任意收款地址。topics 按位置匹配，同一位置的数组表示或关系；若用 blockHash 则不同时加 fromBlock/toBlock。不要把一次日志检索当钱包所有交易、所有 Token 或索引服务的全量历史。
检查结果：范围与合约固定，topics 位置明确；两种区块定位互斥，查询口径没有扩大。
3. 用已确认的严格条件制定切片
公开端点按已读文档最多 1024 区块；私有 5000 的条件在各页不完全一致：方法页写私有，错误页强调 address，Best Practices 写 topics 或 address。此流程只在私有且含 address 时采用不超过 5000 的上限，并核对账户实际更低限制。每片 [a,b] 含首尾数量为 b-a+1，下一片 b+1，最后一片不超过目标终点；官方样例 interval 写法不是可直接复制的含首尾计数。
检查结果：每片数量不超过实际限制，末片截在目标终点，范围连续；未确认的组合保留待核。
4. 逐片读取 HTTP 和 JSON-RPC 错误
保存每片的 HTTP、id、error 或 result。HTTP 200 不足以证明业务成功；范围错误、响应体过大、key 不存在/过期、RU 不足和 QPS 超限分别归类。成功 result=[] 才可记该过滤范围没有匹配日志，失败片不算空片；有 removed=true 的日志按重组撤销单列，保留区块哈希、交易哈希和 logIndex 以复查。
检查结果：成功、失败、未知与撤销日志分开，切片边界和原错误可复现。
5. 复核 Archive 与大日志响应的用量
若现有错误含历史数据缺失，先检查 endpoint 的 Archive 配置，不从查旧区块一律推定要开启。Archive 模式额外消耗 RU；日志响应超过 200 KB 还有按数据量的增量，不能仅按切片数估账单。将 key/网络的已有 Statistics 与具体错误对齐，Success Rate 不等于 1-InvalidRequests/Requests；统计百分比不能替代逐片读取。
检查结果：账户模式、响应大小和方法用量分别记录，Archive/大响应的费用边界与 Gas 分开。
6. 整理缺片与后续修正计划
输出目标区间、过滤器、成功区间、缺片及撤销记录。对于范围超限缩小片长，响应过大收窄查询或进一步分片，凭据失效先核对现有配置；429 不持续无界重试。完整查询也只覆盖所选合约、topics 和区块，不单独证明转账到账、代币合法或交易最终确认；保留这些目标需要的独立证据。
检查结果：计划指向具体失败片及原因，覆盖结论限于声明的过滤范围，未将缺片吞成空数据。
怎样确认完成
- 形成固定过滤范围的切片清单，成功结果、业务错误、缺片与重组日志可追踪。
- 官方文档核验，未生成端点、启用 Archive、发起认证/公共 RPC 或验证真实合约日志。
常见错误与边界
- 私有 5000 区块的过滤条件存在文档差异，此流程不为只有 topics 的请求承诺相同额度。
- 日志页的 arc 示例与 Ethereum 不匹配；旧 Mumbai WS 示例也不能作为当前 Ethereum 入口。
- 区块切片含首尾，b-a 和 b-a+1 会产生一块差异；外层示例还需限制目标终点。
- Archive 与大响应增量不等于链 Gas；统计成功率不等于逐片覆盖率。