误区一：有哈希链接就有完整安全保障
比特币开发指南说明，区块通过哈希关联，全节点依据共识规则独立验证，工作量证明增加重写历史的成本。这些机制共同作用，不能只保留链式数据结构便推断系统具有相同保障。
设计时需要分别回答：数据变动如何被发现，哪些交易应被拒绝，发生竞争历史时如何选择。哈希校验只能覆盖其中一部分；验证规则与历史选择机制也必须明确。
误区二：交易进入区块就永远不会变化
比特币可能出现同一高度的竞争区块，节点在有效候选链中依据累计工作量选择历史。因此，区块高度不具备全局唯一性，交易被收录也不能直接等同于不可逆。
对于需要跟踪链上状态的应用，应区分已提交、已收录和达到业务确认要求等状态，并考虑链重组后的记录修正。这里的适用条件是具体网络的共识与确认机制，不能把比特币的处理方式直接推广到所有链。
误区三：吞吐量越高，扩容方案就越好
以太坊扩容文档将吞吐量、最终确认速度、安全性与去中心化共同纳入目标，并强调节点参与门槛。每秒处理更多交易，并不足以单独证明系统更适用。
性能比较需要匹配业务负载：交易有多复杂、用户需要等待多久、节点承担多少资源成本。只比较一个吞吐量数字，容易遗漏确认延迟和运行条件，使测试结果无法对应实际需求。
误区四：所有链下方案都继承相同安全性
扩容方案的保障来源存在差异：Rollup利用主网数据与验证机制，侧链采用自身共识，Validium则将数据置于链下。它们与主网发生交互，不代表拥有完全相同的信任边界。
评估时可以沿着一次状态更新追问：谁执行，谁验证，验证所需数据在哪里，出现争议后如何处理。即使技术名称相近，也需要检查具体实现，不能仅凭“连接主网”判断安全属性。
常见问题：是否存在通用的最佳架构
这些机制适用的场景不同，无法仅凭区块链或扩容方案的名称确定最佳架构。需要先明确参与者之间的信任关系、确认要求以及数据验证需求，再判断技术组合是否满足条件。
同样，基础链的安全机制不能自动证明应用业务逻辑正确。协议层能够验证什么、应用层还需检查什么，应分别界定；系统设计的关键是让每项保障都有对应机制和适用边界。