一、运行安全保障到哪里
区块链运行安全的应用边界是什么，核心在于区分“按规则执行”与“规则本身正确”。网络可以验证交易是否符合协议，合约可以按照代码更新状态，但这些机制不能自动判断业务设计是否合理，也不能替应用消除授权失误。安全结论必须说明保护对象和成立条件，不能仅用“已经上链”概括。
二、账本层：一致性不等于绝对不可改写
比特币开发文档说明，全节点独立验证区块，区块通过哈希连接，工作量证明增加修改历史的成本；出现竞争分支时，节点在有效链中依据累计工作量选择链。因此，其保护重点是交易记录的一致性与防止重复花费，不能简单理解为记录一经出现便永远不变。
这一机制的适用条件包括遵守共识规则和相应的网络安全假设。业务系统不能把看到交易、交易进入区块与历史稳定性视为同一件事，也不能把比特币的工作量证明结论直接套用到所有区块链。
三、合约层：执行正确不代表业务正确
以太坊智能合约安全文档强调访问控制、输入检查、测试和独立审查。公开可调用的函数涉及敏感操作时，需要额外授权；多签可以提高敏感操作的批准门槛。审计不能发现所有漏洞，形式化验证的结论也受所验证的性质、模型和假设限制。
例如，业务原本要求只有指定角色能够修改参数，但代码遗漏权限检查，网络仍可能正常执行这次修改。此时账本未必遭到破坏，应用却已经违反业务要求。这说明底层共识无法代替应用权限设计。
四、安全措施的适用条件
权限划分只有在角色配置符合职责、密钥得到妥善管理时才有意义。增加管理员数量并不自动消除单点风险，还要看单个角色是否仍能独立完成高危操作。测试则需要覆盖异常输入、边界状态和调用组合，仅验证正常流程不足以证明安全。
五、常见问题
不可篡改能否保护有漏洞的合约？不能。它有助于约束历史记录的修改，却不会修正已存在的逻辑错误；缺少预先设计的升级机制时，缺陷修复还可能更加困难。
通过审计是否就能认定应用安全？不能。审计针对特定代码和检查范围，后续代码、配置或权限变化都可能改变风险。判断应用边界，应分别核对共识保障、合约规则、授权条件与验证范围，而不是把任何单项措施当作整体安全保证。