把数据采集当成数据挖掘
区块链数据挖掘涉及数据获取、字段整理、关系建模和结果解释。接口返回记录，只完成了获取环节。统计、关联分析或图分析是否有效，取决于研究对象和字段含义是否匹配。
以太坊 JSON-RPC 文档区分状态查询和历史记录查询，并说明区块参数影响状态读取的位置；数量与字节数据虽都使用十六进制，但编码规则不同。比特币开发指南则说明，普通交易的输入引用此前的输出，未花费输出构成 UTXO。这些差异决定了分析前需要先识别数据模型。
误区一：用当前状态代替历史变化
查询某个时点的余额，能够回答该时点的状态问题，却不足以说明余额如何形成。分析变化过程时，应明确需要状态快照还是历史交易记录，避免把两者直接替代。
连续使用 latest 查询，也不能预设各次结果对应同一区块。需要比较同一时点的数据时，应统一区块口径；pending、safe 与 finalized 的含义不同，不能作为相同条件混合统计。
误区二：把十六进制字段统一转成数字
金额等数量字段需要按数值解释，地址、哈希等字节字段则需要保留其数据结构。若一律删除前导零或转换为数字，可能破坏标识信息，影响关联与去重。
清洗规则应按字段类型制定。检验关联结果时，先确认连接键是否保持完整，再检查分析算法；否则，格式处理错误可能被误认为链上关系缺失。
误区三：跨链直接套用同一种交易图
比特币普通交易的输入通过交易标识和输出索引定位此前输出。进行花费关系分析时，仅按交易标识连接，可能无法区分同一笔交易中的不同输出。该规则的讨论还需注意 coinbase 交易的特殊性。
建立图模型之前，应说明节点代表交易、输出还是地址，边代表引用关系还是其他关系。不同定义回答不同问题，不能因为图形相似，就把比特币输出关系与以太坊账户状态视为同一种对象。
误区四：把技术关联扩大为身份结论
输入引用某个输出，可以支持花费关系的判断；它本身不能证明相关地址属于同一现实主体。技术记录能够验证的关系，与身份或行为动机推断，需要分别表达。
常见问题是：数据能够成功读取，是否就足以支持结论？仍需检查字段含义、区块范围和模型假设。结果说明应写清分析单位与适用范围，使读者能够分辨直接观察到的记录和依赖额外证据的解释。