误区一：全量数据有统一的含义
讨论“全量”之前，需要先说明包含什么：区块与交易记录、当前状态，还是各历史区块对应的状态。不同范围解决的问题不同，不能仅凭“全量”二字判断数据服务是否满足需求。
以太坊开发文档区分了交易历史与历史状态：状态包含账户余额、合约代码和存储等信息，归档节点用于保留历史状态。比特币开发指南则从交易输入、输出和未花费交易输出解释账本。两种模型提示我们，描述数据完整性时必须限定具体链与数据对象。
误区二：全节点就是归档节点
“能够验证网络”和“保留每个历史状态”是不同能力。在以太坊的语境中，全节点跟随并验证最新状态，旧状态可以被裁剪；归档节点则提供历史状态存储能力。
例如，确认某笔交易包含在哪个区块，与查询某账户在该区块执行结束后的余额，所需数据不同。因此，节点名称之外，还应明确历史覆盖范围及接口支持情况。
误区三：能重建就能立刻查询
历史状态在具备必要历史数据的条件下，可以通过重新执行交易推导出来，但重建需要计算。归档的价值在于减少查询旧状态时的重放工作，代价包括额外存储和维护成本。
常见问题是：查历史交易是否一定需要归档节点？关键在于查询对象。读取交易记录与读取历史合约状态不能混同，是否需要归档能力取决于接口和数据保留方式。
误区四：当前状态足以代表全部历史
比特币的未花费交易输出集合反映哪些输出仍可用于后续支付，已花费输出也是交易历史的一部分。因此，当前可用输出的集合不能替代完整交易记录。
同样，当前账户余额只能回答当前状态问题。若要解释余额如何形成，或比较不同区块时点的状态，需要相应历史数据及处理能力。
误区五：区块高度是唯一标识
比特币开发指南指出，分叉期间同一高度可能存在多个区块，区块哈希用于区分它们。整理历史数据时，仅记录高度可能造成歧义。
需要复核的数据结果，应同时明确所属网络、区块哈希及其所在分支。对于链头附近的数据，还要考虑链重组对记录归属的影响。
误区六：保存越多就越适用
普通网络交互通常不要求查询所有历史状态；研究、审计或历史状态服务则可能有这类需求。判断适用性，应从实际问题出发：需要哪些字段、覆盖哪些区块、是否频繁读取旧状态。
存储容量和查询速度受客户端实现、配置及硬件影响，不能把某份配置中的数值当作所有节点的固定标准。数据范围明确后，才能合理评价所谓“全量”的完整性与可用性。