一、账本难以篡改，应用就安全吗？
区块链安全需要分层理解。比特币开发者指南介绍的哈希关联、工作量证明和节点验证，主要涉及账本记录及共识；以太坊开发者文档中的权限、测试与审计，主要涉及智能合约逻辑。
账本按规则记录一次调用，并不代表调用符合应用设计者的意图。如果合约错误地允许任何人执行管理操作，底层网络仍可能正常执行它。因此，评估安全性首先要明确保护的是交易历史，还是应用中的权限和状态。
二、防双花是否意味着历史绝不会变化？
比特币节点会检查交易使用的输出是否尚未花费，拒绝在同一有效链中重复使用同一输出。区块之间的哈希关联与工作量证明共同提高修改历史的成本。
这一机制不等于历史绝对不可调整。网络可能暂时出现竞争分支，并在有效分支中依据累计工作量选择链。理解这类安全保证时，需要保留其共识条件，不能把比特币的机制直接套用于所有区块链。
三、公开函数如何限制敏感操作？
以太坊合约中的函数可见性与业务授权是两个问题。允许外部调用的函数，仍可通过访问控制限制谁能执行敏感操作。设计时应逐项明确哪些账户可以修改参数、暂停功能或进行升级。
角色分工可以缩小单个账户的权限范围，多签可以要求多个参与方共同授权。但多账户配置不自动等于独立控制；如果关键权限仍集中在同一控制者手中，集中风险依然存在。
四、条件检查能替代完整设计吗？
require 和 revert 可用于拒绝不满足条件的操作，assert 主要用于检查内部逻辑应始终满足的不变量。检查是否有效，取决于条件有没有覆盖真正的业务约束。
例如，验证调用者身份与验证操作后的状态是否合理，解决的是不同问题。只检查身份，无法排除有权限的调用触发错误逻辑；只检查输入，也无法代替权限限制。
五、测试和审计通过是否足够？
单元测试覆盖预设场景，静态分析、模糊测试及独立审查可从其他角度发现问题。形式化验证的结论也受规格、模型和假设约束，不能理解为对整个系统的无条件保证。
阅读安全结论时，应关注检查了哪个代码版本、覆盖哪些性质，以及哪些依赖未被纳入。后续代码或权限配置发生变化，原有结论的适用范围也需要重新评估。