先明确“重启”和待核验结论
本文讨论节点软件重启后的数据核验，不把单个节点重启等同于整个区块链网络重启。核验前应明确问题：节点是否恢复处理、是否追上链状态，还是某段历史数据仍可查询。这些结论需要不同证据，不能仅凭“启动成功”相互替代。
技术文档说明系统如何工作，具体节点记录说明某次运行发生了什么。只有文档而没有重启前后的记录，可以解释核验思路，但不能认定某个项目已经证明数据未丢失。
两个来源分别支持哪些判断
ethereum.org 的 Nodes and clients 文档说明，以太坊节点由执行客户端与共识客户端协作运行，按协议规则验证数据；节点的数据保存范围与同步方式有关，归档节点用于保留历史状态。这些概念有助于区分运行状态与历史查询能力。
developer.bitcoin.org 的 getblockchaininfo 文档列出网络名称、已验证区块高度、区块头数量、最佳区块哈希、验证进度估计和裁剪状态等字段，可用于描述比特币节点的链处理状态。
两个来源针对不同系统，不能视为对同一次重启的交叉验证，也不能把比特币字段直接当作以太坊节点的核验标准。具体字段与行为还应对应实际客户端版本。
建立可比较的前后记录
核验记录应注明网络、客户端版本、采集时间、数据范围及同步或裁剪配置，让重启前后的结果具有可比性。比较具体数据时，应固定目标区块，而不是只比较不断变化的链顶。
在比特币场景中，可以结合上述接口的区块高度、区块头数量和最佳区块哈希描述节点状态。高度相同不等于区块相同；前后链顶不同，也不能直接判定数据损坏，需要先区分比较对象变化与目标数据变化。
验证进度在文档中被定义为估计值，因此不宜单独作为完整性证明。若结论涉及某笔交易或某段历史记录，还需要相应数据的核验记录，节点状态摘要本身并未展示这些具体内容。
适用条件：保存策略决定证据范围
历史数据查询能力必须结合保存策略解释。以太坊历史状态与比特币历史区块是不同对象，不能因为两者都有裁剪或归档相关概念，就假定保存规则一致。
如果要声称“重启前后某范围数据一致”，应说明核验的区块范围、具体对象和比较结果。如果只检查少量对象，结论也应限于这些对象，不应扩大为全部历史数据完整。
常见问题与结论边界
查询不到旧数据是否就是重启造成丢失？不能直接这样判断。应先确认节点原本是否保存、是否支持查询该类数据，再比较前后记录。保存策略造成的不可用与重启造成的变化需要分开讨论。
两个网站都介绍节点验证，是否足以证明重启安全？不足。文档提供解释依据，不是具体事件的实测报告。可靠的核验结论应同时交代技术依据、实际记录、比较范围和未验证部分，避免把一般原理写成某个项目已经得到证实的结果。