一、先区分账本安全与合约安全
区块链合约安全涉及两个层面：底层网络判断交易和区块是否符合规则，合约代码决定具体操作是否允许。网络正确执行一段有缺陷的代码，并不意味着应用行为符合开发者的预期。
以太坊开发文档的合约安全章节侧重权限、条件检查、测试和独立审查；比特币开发指南的区块链章节侧重交易记录、共识及区块关联。两者有助于理解不同安全边界，但不能把比特币的交易模型直接套用到以太坊合约。
二、共识、哈希与UTXO是什么
共识规则是节点验证区块和交易时遵循的规则。哈希将数据映射为摘要；比特币区块通过前一区块头的哈希相连，默克尔根则汇总区块内交易的哈希关系。UTXO指未花费交易输出，是比特币判断可花费输入的基础。
这些术语描述账本如何组织和验证记录，不负责判断应用权限设计是否合理。例如，一笔操作即使符合链上验证规则，仍可能利用合约遗漏的权限检查。
三、可见性不等于访问授权
public和external涉及函数的调用方式，不代表调用者已获准执行敏感操作。访问控制才负责检查“谁可以做什么”。Ownable通常以所有者身份限制操作；基于角色的控制则把不同权限分配给不同角色。
多签通过要求多个签名共同批准操作，提高敏感权限的使用门槛。角色分离和多签都需要结合实际配置理解，不能仅凭名称认定已消除单点风险。private也不是数据保密措施，函数调用限制与链上信息可见性属于不同问题。
四、回滚与不变量如何理解
在Solidity中，require通常检查输入、权限或执行条件；revert用于主动报告失败；assert用于检查内部逻辑应始终满足的性质。检查失败会使相应执行范围内的状态修改回滚。
不变量是预期始终成立的约束，例如总量不得超过设计上限。它不是一条自动生效的安全承诺：如果约束定义遗漏了重要业务关系，即使现有断言全部通过，也可能存在逻辑缺陷。
五、测试、形式化验证和审计的边界
单元测试检查选定场景，模糊测试通过生成输入寻找异常，静态分析不依赖实际执行来检查代码特征。形式化验证则针对明确的模型、假设和性质进行证明，其结论不能扩展为“整个系统没有任何漏洞”。
常见问题是：经过审计是否就能放心？审计属于额外的独立检查，并非无漏洞保证。阅读安全教程或评估验证结论时，应关注检查了哪些代码、覆盖哪些性质，以及依赖什么假设，而不只看是否使用了某项安全工具。