先确定核验对象与适用范围
“挖矿交易”需要结合具体区块链理解。对采用比特币式区块结构的网络，应先确认交易所属区块、区块高度和区块哈希，再判断该区块是否属于节点当前认可的有效链。仅看到一笔交易哈希，不能单独证明它属于目标网络，也不能证明节点已经同步到包含该交易的链。
提供的材料分别介绍了比特币链状态 RPC 和以太坊 JSON-RPC。它们能够帮助核验网络、同步和区块定位信息，但材料没有给出一个适用于所有项目的“挖矿交易真伪”统一字段。因此，具体项目若使用了改造版客户端，还应以该项目的节点文档和共识规则为准。
比特币网络参数的核验重点
比特币节点的 getblockchaininfo 返回链状态对象。其中，chain 用于识别当前网络名称，例如主网、测试网或回归测试网络；blocks 表示节点已完整验证的最有工作量链高度；headers 表示已验证的区块头数量；bestblockhash 表示当前最佳区块哈希。这些字段应结合查看，而不能只依赖单一高度。
difficulty 是当前难度，mediantime 是当前最佳区块的中位时间，chainwork 是活动链累计工作量的十六进制表示。核验时可以记录查询时间与这些字段，并将交易所在区块的高度、哈希和区块头信息进行对应。若节点仍处于 initialblockdownload，或 warnings 存在网络与区块链警告，应把结果视为同步中的状态，而不是最终确认。
如果节点启用了剪枝，返回结果还可能包含 pruneheight，表示本地保存的最低完整区块高度。此时，即使网络参数和链头正确，节点也可能无法提供较早区块的完整数据。核验历史挖矿交易前，应先确认交易所在高度不低于可用的本地区块范围，或改用保留完整历史的节点。
以太坊网络参数的核验重点
以太坊 JSON-RPC 提供的字段体系不同。net_version 用于返回网络标识，web3_clientVersion 可用于了解节点客户端版本，net_listening 和 net_peerCount 可辅助判断节点是否正在监听网络及当前连接的对等节点数量。这些信息主要说明节点所处网络和连接状态，不能单独证明某笔交易已经被区块最终确认。
eth_blockNumber 返回节点当前区块高度；查询区块和交易时，应继续使用相应的区块或交易读取方法，将交易哈希、所在区块和区块哈希相互对应。eth_getTransactionReceipt 可用于查看交易回执，但材料同时说明，不同客户端可能在返回内容和同步信息上存在差异，因此不能把某一客户端的扩展字段当成所有节点都具备的标准。
eth_syncing 在同步进行时返回同步状态对象，不同步时返回 false。核验时应关注节点是否仍在追赶链头，并区分 latest、safe、finalized 等区块参数语义。查询状态类数据时，明确使用的区块范围很重要，否则同一账户或合约数据可能因查询区块不同而得到不同结果。
编码与一致性检查
以太坊 JSON-RPC 对数量和字节数据采用十六进制表示，但规则不同：数量需要 0x 前缀并使用紧凑形式，零表示为 0x0；哈希、地址和字节数组也需要 0x 前缀，并按字节使用偶数位十六进制。将数量误当作字节数组，或省略前缀、加入不必要的前导零，都可能导致请求失败或解析错误。
跨节点核验时，应固定同一条链、同一个区块高度或区块哈希，并比较链标识、区块哈希、交易哈希和同步状态。比特币侧重点是 chain、blocks、headers、bestblockhash、difficulty、chainwork 等字段；以太坊侧重点是 net_version、客户端版本、区块高度、同步状态以及交易所在区块。两套字段不能直接互换。
常见问题
问题一：交易能查到，是否就说明是挖矿所得？不一定。能够查询到交易，只能说明节点或服务提供了相关记录。还需要根据该链的区块结构、交易类型和共识规则，确认它是否属于区块奖励、手续费分配或其他普通转账。提供的材料本身没有定义所有链的挖矿交易判定规则。
问题二：节点显示的区块高度与网页平台不同怎么办？先检查网络标识、节点同步状态和查询时点，再比较最佳区块哈希，而不是只比较高度。若网络标识不同，可能是主网与测试网混淆；若标识相同但链头不同，则应等待同步完成或使用多个独立节点复核。
问题三：核验结果能否直接作为资产或交易决策依据？不能。RPC 核验只能提供节点状态、区块定位和交易读取信息，不能替代对私钥安全、交易目的、项目规则、服务方可信度或资产风险的独立判断。