把数据接口当成挖掘方法
区块链数据挖掘包括数据获取、整理和解释。以太坊开发者文档介绍的JSON-RPC提供节点交互方式，本身不负责发现行为规律。取得区块或余额后，仍需定义研究对象、统计口径和判断依据。
例如，研究某一时点的余额分布与研究一段时间的交易活动，需要不同的数据组织方式。接口能够返回结果，并不意味着结果足以回答研究问题。
混用当前状态与历史记录
以太坊接口区分状态查询与历史记录查询；状态查询中的区块参数决定观察位置，latest、pending和finalized等标签含义不同。数量与字节数据虽然都使用十六进制表示，编码规则也不同。客户端的具体支持情况还需分别确认。
常见错误是将不同观察位置的结果直接合并，或把编码相似的字段采用同一套转换规则。进行横向比较时，应统一区块口径，保留字段类型，并区分查询失败、数据缺失与真实零值。这些条件决定统计是否可复核。
把比特币交易简化成账户流水
比特币开发者指南说明，普通交易的输入引用此前的输出，引用依靠交易标识和输出索引；未花费输出构成UTXO。指南中的P2PKH用于展示一种具体的支付与解锁结构，不能代表所有交易形式。
因此，构建交易关系图时，应先明确节点代表交易、输出还是地址。若忽略输出索引，只按交易标识连接记录，就可能丢失具体输出的对应关系。以账户余额为中心的分析口径，也不能直接套用到UTXO结构上。
把链上关联解释成现实身份
输入引用输出能够支持交易结构上的关联分析，但单凭这类关联，不能确认现实中的人员身份或行为目的。图中存在连接，与能够解释连接背后的业务含义，是不同层次的结论。
解释聚类结果时，应写清哪些关系来自原始记录，哪些属于分析假设。缺少独立证据时，结论宜停留在可观察的交易关系范围内。
常见问题与适用条件
不同链能否共用分析方法？统计、图分析等思路可以借鉴，但数据模型、字段含义和关联规则需要分别定义。本文的接口讨论适用于以太坊相关查询，UTXO讨论针对比特币交易结构。
数据越多是否越准确？增加记录不能修复错误口径。开始分析前，应明确研究时间范围、观察单位和缺失数据处理方式；输出结果时保留这些条件，才能让他人判断结论适用于什么问题。