误区一：记录难以篡改，内容就一定真实
比特币开发者指南说明，区块通过哈希关联，节点依据共识规则验证记录。这些机制支持账本一致性，并提高改写历史的成本，但无法直接证明链外事实。
例如，一条业务记录即使被完整保存，也仍需核实录入者身份及原始凭证。设计应用时，应分别回答“记录是否被修改”和“记录最初是否准确”，不能用前者代替后者。
误区二：交易进入区块，就绝不会变化
比特币网络可能出现短暂分叉，节点会在有效分支中依据累计工作量选择链。因此，交易被某个区块收录与获得更稳定的确认并非同一状态。
应用界面和后台流程应区分提交、收录与确认，考虑链重组对业务状态的影响。这一说明针对比特币相关机制，其他区块链的最终性需要按各自协议理解。
误区三：使用区块链，就没有管理者风险
以太坊智能合约安全文档强调，敏感操作需要访问控制；多签和角色划分可以降低部分权限风险。底层网络的分布式运行，并不意味着应用管理权也充分分散。
评估系统时，需要看谁能暂停服务、修改参数或执行升级。多个管理地址如果仍由同一主体控制，也不能仅凭地址数量认定权力已经分散。
误区四：公开函数或私有函数名称能够代替授权
函数可见性规定调用范围，业务授权则规定调用者能做什么。对外开放的合约入口仍需校验身份、输入和当前状态。
例如，普通查询与敏感管理操作可以同时存在，但后者需要独立的权限限制。界面隐藏按钮无法替代合约内部检查，因为外部账户可能绕过界面直接调用合约。
误区五：测试、审计通过就代表没有漏洞
以太坊安全文档将测试与独立审查视为互补措施，审计不能发现所有问题。形式化验证也只能在既定模型、假设和性质范围内提供证明。
常见问题是只检查正常流程，遗漏异常输入、权限组合及连续操作。审查结果应对应明确的代码版本；后续修改后，原有结论是否仍适用，需要重新评估。
误区六：合约部署后可以像普通服务一样修补
已部署合约代码通常不能直接修改。即使系统预先设计了升级机制，也仍需考虑升级权限、状态兼容和异常处置。
这些认识主要适用于具有链上合约的应用。具体系统是否可升级、由谁批准、修改影响哪些规则，都应依据实际设计判断，不能从“使用区块链”直接推导答案。