链上观察区间：区块、最终性与缺失历史
链上统计要能复现，必须记录网络、区块边界、最终性规则、查询方法和缺失处理。“上个月”不是完整规范，两个正确查询也可能因为覆盖区块或历史能力不同而得到不同结果。
Ethereum JSON-RPC 参考说明查询链上信息的方法与区块参数，但具体提供方是否支持所需历史和参数，仍要核查。文档存在某方法，不证明所有端点具有相同保留范围和服务行为。
将时间转换为区块选择规则
先用明确时区写出起止时间，再说明怎样映射到区块。决定是否包含起点、排除终点，或采用另一种清楚约定。这个细节可以避免把相邻期间相加时重复统计边界。
保存网络标识、端点类型、查询参数、抓取时间，必要时保存区块哈希。历史状态问题要区分在目标区块读取的值，与今天读取后放进旧日期表格的值，两者不能替换。
| 查询记录 | 必要信息 |
|---|---|
| 研究区间 | 起止、时区、纳入规则 |
| 链上范围 | 网络、资产和合约 |
| 区块范围 | 编号及相关身份记录 |
| 状态约定 | 历史、最新或其他选择 |
| 覆盖 | 成功区间与缺失响应 |
| 修订政策 | 重组和重新查询的处理 |
另一位研究者应当能依据记录重建问题，而不需要猜原脚本的意图。
假设案例：午夜边界被算两次
假设虚构数据集统计周一零点至周二零点的转账，脚本同时包含两个端点，次日脚本又包含周二起点。把每日数据相加时，共享边界可能被算两次。
左闭右开的约定可以避免这类重叠：包含起点，排除终点。重点是明确且一致执行，而不是声称所有服务早已采用相同规则。长区间处理前，先用小样本检查边界。
再假设某段区块请求返回不完整。把空响应当零活动会低估统计，应先标记缺失，直到确认查询完整，或用适当替代来源补齐。此例只是方法示意，不描述某个实际端点。
先检查覆盖，再解释变化
建立覆盖台账，列出请求区间、成功区间、重试和未解决缺口。分批请求时核对既没有遗漏也没有重叠，记录去重前后数量及使用的键。最终总数看起来合理，不能代替覆盖检查。
近期观察要注明最终性约定，以及重跑后是否可能修订。历史问题则确认来源能够返回所需状态，而不只是交易历史；有些问题仅靠日志无法回答。
另用合适的方法独立复现一小段，目的是检查字段含义和完整性，不只是获得相近总额。两个脚本共享同一个错误也会相互一致，因此还要查看起点、中间和终点的具体记录。
边界与常见错误
提供方限制、链重组、缺少合约范围说明和历史状态不可用，都可能导致结果不完整。此时报告实际覆盖，不给精确的整个期间结论，更不能默默插值补成完整历史。
常见错误包括 UTC 与本地日期混用、共享端点重复、把请求失败视为零、用当前状态回答历史余额，以及漏写网络。研究笔记要说明按本次约定哪些观察已经确定，哪些仍可修订。这里处理的是现货研究证据工程，不是交易信号。
覆盖台账也要标注补齐方式。通过其他来源补回的数据，应保留原始缺口和替代来源身份，不能让最终完整表掩盖曾经缺失的事实。
常见问题
只保存交易时间戳能复现数据集吗？
不能。还要保存网络、区块选择、方法、合约范围和缺失处理。
空响应应该总是记成没有活动吗？
不是。先确认查询成功且覆盖完整，缺失或截断响应不是实测零值。