一、误以为每个节点都保存相同的数据
分布式账本不等于所有参与者都持有完全相同的本地数据库。以太坊节点存在不同运行方式：全节点侧重数据验证，归档节点保留历史状态以支持查询，轻节点则利用较少的数据和证明进行验证。
因此，判断一个节点能提供什么数据，不能只看它是否连接区块链网络，还要看节点类型、同步方式和实际保留范围。
二、误以为全节点就是完整历史查询库
“能够验证区块”与“能够直接查询任意时点的状态”不是同一件事。以太坊的当前状态、历史状态和区块交易记录应当分开理解，普通全节点并不必然保留全部历史状态。
例如，查询某个旧区块时的账户余额，与查询当前余额，对存储能力的要求不同。历史状态查询通常需要归档能力；不能因为节点能正常验证新区块，就认定它能立即回答所有历史问题。
三、误以为节点裁剪就是篡改账本
裁剪是本地数据保留策略，不等于改写网络认可的交易记录。删除某些不再保留的历史数据，与改变已经验证的记录内容，属于不同操作。
需要注意，节省本地空间可能影响历史查询和数据提供能力。选用裁剪方式时，应先区分需求是验证当前链，还是长期提供历史数据，不能把两种用途混为一谈。
四、误以为哈希和区块头能够代替原始数据
比特币区块头中的默克尔根用于承诺区块内的交易内容。结合交易及相应证明，可以检查该交易是否被包含在区块中，但不能仅凭这个根还原全部交易。
这也解释了为什么轻量验证仍可能需要其他节点提供数据：摘要帮助核验内容，却不是原始内容的替代品。“可以验证”与“已经存有全部数据”必须分别判断。
五、误以为记录入块后绝不会变化
比特币网络可能暂时出现同一高度的竞争区块，节点随后依据共识规则选择累计工作量更高的有效链。因此，刚进入某个区块，不应被理解为绝对不会发生链重组。
区块高度也不能在所有情况下唯一标识区块。需要精确定位时，应区分高度与区块哈希，避免把竞争分支上同高度的区块当成同一个对象。
六、误以为一种链的存储规则适用于所有链
比特币以未花费交易输出描述可花费资金，以太坊则涉及账户与合约状态。两者都使用区块和密码学验证，但不能据此推断它们的数据组织、历史查询和裁剪方式完全一致。
实际理解存储能力时，可以依次确认三个问题：保存的是原始交易还是状态？需要当前数据还是历史数据？数据可以直接查询，还是需要额外获取或重建？这些区别比“是否保存整条链”更准确。