误区一：用哈希连接就能保证历史绝对不变
比特币开发文档介绍，区块通过前一区块头的哈希连接，交易则通过默克尔根与区块头关联。修改交易会破坏原有哈希关系，但抵抗历史重写还需要工作量证明和节点验证规则共同发挥作用。
因此，哈希链接提供的是可检验的关联。评估数据是否可靠，还要区分结构是否匹配、交易是否有效，以及所在分支是否被网络接受。
误区二：默克尔根保存了全部交易内容
默克尔根是逐层计算得到的哈希摘要，无法据此还原全部交易。结合区块头和必要的中间哈希，可以验证某笔交易是否被该区块包含。
这类证明适用于核验包含关系。它不能单独证明整条链上的交易都有效，也不能替代原始数据保存；应用需要展示交易详情时，仍需取得相应数据。
误区三：交易历史就是当前状态
以太坊区块文档描述了交易执行与状态更新的关系：交易按顺序执行，产生新的状态，节点通过重新执行来校验结果。交易记录说明发生过什么，状态描述执行后的结果。
这一区分直接影响查询设计。查询历史过程和查询当前结果需要不同的数据视角。区块中的交易顺序也具有执行意义，不能为了分类方便而任意改变。
误区四：不同区块链采用同一种账本模型
比特币以未花费交易输出组织可供后续花费的数据；以太坊则围绕账户及相关状态执行更新。两者的数据关系和验证对象存在区别。
设计通用数据接口时，可以统一部分展示字段，但底层解析仍需遵循各自规则。例如，不能把交易输出直接理解成另一种系统中的账户余额记录。
误区五：区块高度可以唯一标识区块
比特币发生分叉时，同一高度可能存在多个候选区块。高度表达位置，区块哈希用于区分具体区块；选择有效分支还涉及累计工作量。
因此，历史数据索引若只保存高度，可能混淆不同分支。需要精确关联交易与区块时，应同时保留区块身份和分支归属。
常见问题：区块越大、出块越规律就越好吗
以太坊用时隙安排区块提议，但时隙可能为空，不能将调度间隔理解为每次必然产生区块。其执行容量还受 gas 限制，gas 衡量执行资源消耗，不能直接当作字节数。
扩大容量需要考虑节点处理与传播负担。讨论数据组织效率时，应明确比较的是存储空间、验证成本还是查询速度，单看每块交易数量不足以判断整体效果。