误区一：区块链只有一种链式结构
比特币开发者指南介绍了区块之间的哈希连接、区块内交易的默克尔树，以及交易输出之间的引用关系。以太坊开发者文档则介绍了用于组织键值数据的默克尔帕特里夏树及其底层数据库。这些结构解决的问题不同，不能用“按顺序排列的数据块”概括全部组织方式。
理解一种结构时，应先确定对象：它组织的是区块历史、交易集合，还是账户状态。不同对象的关联方式和验证需求不同，某种结构的特点不能直接推广到所有区块链。
误区二：有哈希就能保证历史绝不改变
哈希关联使数据修改能够被检查出来，但历史选择还涉及共识规则。在比特币中，节点验证区块，并在有效候选链之间依据累计工作量选择链。
因此，“发现内容变化”和“让网络接受某段历史”是两个问题。前者依赖密码学关联，后者还需要协议规则与相应安全条件。将不可篡改理解为任何情况下都无法发生历史重组，会遗漏这些条件。
误区三：默克尔证明能证明一切
默克尔证明用于检查某项数据与指定根之间的关系。交易被包含在一个区块中，并不单独证明该区块已被目标网络接受，也不替代交易有效性检查。
常见问题是：拿到证明是否就无需其他验证？仍须确认根的来源和所对应的区块或状态。证明回答的是特定数据关系，不能自动回答现实业务信息是否真实。
误区四：树根就是压缩后的完整数据库
树根是用于验证的摘要，不能凭它还原全部账户、交易或合约数据。检查数据关系还需要相应数据及证明节点。
这一区别适用于轻量验证和数据保存设计：能够验证别人提供的内容，不等于自己拥有完整内容；保存一个根，也不等于完成了数据备份。
误区五：逻辑树查找等于一次数据库读取
以太坊文档区分了树上的路径遍历与底层键值数据库查询：沿路径寻找目标可能涉及多次读取，路径压缩用于减少不必要的层级。
因此，讨论查询效率时，需要说明衡量的是逻辑步骤还是实际存储访问。仅凭数据结构名称或理论复杂度，无法确定具体系统的响应速度，缓存和数据布局等实现条件也需要纳入考察。
误区六：区块高度可以唯一标识区块
比特币可能出现同一高度的竞争区块，因此高度不能作为全局唯一标识，区块通常通过区块头哈希引用。
查询“某高度的数据”时，还应明确所查询的链及其当前选定历史。高度适合表示位置；需要精确引用某个区块时，应使用能区分竞争区块的标识。