区块链的安全能力有哪些边界
理解区块链安全，需要区分账本记录与应用逻辑。比特币开发文档介绍了哈希链接、工作量证明和节点验证如何共同约束历史记录修改与重复花费；以太坊智能合约安全文档则讨论权限、代码检查和独立审查。两者分别说明：记录的维护机制与记录上运行的程序，需要各自满足安全条件。
因此，评估一个应用是否安全，不能只看它是否使用区块链。还要看业务要求由哪一层实现，以及该层能否处理错误输入、越权操作和异常状态。
难以篡改是否意味着记录绝不会变化
比特币通过区块之间的哈希关联及累计工作量，提高改写历史的成本。网络可能短暂出现竞争分支，节点依据共识规则选择累计工作量最大的有效链。算力攻击也可能影响交易历史，因此，刚进入区块的记录仍存在被重组的可能。
这里的适用条件是比特币的工作量证明机制，不能直接套用于所有区块链。应用若把首次收录视为永久确定，就可能在链上记录变化后出现业务状态不一致。
谁有权执行敏感操作
智能合约的外部入口需要明确的授权检查。单个管理员密钥失陷可能危及其控制的功能；角色分工和多签可以降低部分风险，但角色划分本身不等于多方共同批准。
权限设计需要同时回答两个问题：某个账户能做什么，以及一次敏感操作需要谁同意。若多个角色最终仍由同一主体控制，仅增加账户数量也难以形成有效制约。
代码能执行是否代表逻辑安全
合约需要验证输入、调用权限和状态条件，并在条件不满足时回退相关状态变更。已部署逻辑的修复受合约设计约束，因此，错误处理必须在部署前纳入设计。
例如，一项操作即使符合输入格式，也可能不符合当前业务状态。检查应覆盖操作前提与执行后的关键约束；异常回退只能阻止已被识别的违规情况，遗漏的规则仍可能留下缺陷。
测试和审计能否保证没有漏洞
单元测试、静态分析、模糊测试和独立审查可以相互补充，审计不能保证发现全部问题。形式化验证的结论也受所定义的性质、模型及假设限制。
常见误区是把正常流程测试通过等同于安全验证完成。安全检查还需要考虑边界输入、异常调用顺序和权限变化。判断验证是否充分，应关注检查覆盖了哪些风险，而不能只看是否具有测试或审计记录。