先确认城市节点对应什么对象
“城市节点”需要结合具体平台理解。这里讨论以太坊与比特币接口支持的通用查询方式，不将其视为某个项目已经具备的功能。两类接口说明均未定义按城市名称检索资料修改历史的专用方法。
查询前需要明确所属网络、资料所在系统，以及可关联的合约地址、交易哈希或区块哈希。若只有一个城市名称，缺少它与链上对象之间的对应关系，就无法确定该查询哪条记录。
区分资料内容与链上记录
资料更新可能指业务字段变化，也可能指节点同步到了新的区块。二者需要分别核对：同步进度描述节点处理区块的情况，不能直接说明城市介绍、联系方式等业务资料发生了修改。
还需要确认链上实际保存的内容。若业务系统只把资料摘要关联到交易，查询交易并不等于取得完整资料；要了解修改前后的文字内容，还需查阅相应业务系统保存的版本记录。是否存在这种设计，应以具体平台的说明为准。
以太坊接口能提供哪些线索
以太坊 JSON-RPC 文档将查询方法区分为状态与历史等类别。eth_getTransactionByHash 可查询交易，eth_getTransactionReceipt 可取得交易回执，eth_getBlockByNumber 可查询区块。eth_call 和 eth_getStorageAt 等方法支持通过区块参数指定查询状态的高度。
这些方法提供核对所需的数据入口。要把结果解释为某条城市资料的更新，仍须知道业务字段与合约数据的对应关系。指定某个区块的状态，也不等于接口自动生成了完整的修改清单。
比特币接口适合核对什么
比特币开发者参考文档中的 getblock 以区块哈希为查询条件。按该文档，verbosity 为 1 时返回区块信息及交易标识，为 2 时还包含交易详情；结果可包括区块高度、区块时间和确认数。
因此，已知资料关联交易所在的区块时，可以进一步核对区块与交易信息。但 getblock 不提供按城市名称查找资料版本的能力，区块时间也不应直接当作业务人员修改资料的时间。
查不到记录时如何判断
查不到记录，不能立即认定资料从未更新。应分别核对网络是否正确、标识是否匹配，以及资料是否确实存在对应的链上记录。只有交易信息而没有业务字段说明，也不足以还原具体修改内容。
一份可核对的更新记录，应明确资料对象、关联交易、所在区块及版本对应关系，并区分业务修改时间与区块时间。如果缺少版本内容或关联依据，查询结论应限定为已查到的链上信息，不扩展为完整的资料变更历史。