共识能保证业务逻辑正确吗
讨论“老程序员谈区块链技术有哪些常见问题”，首先要区分两个层面：节点按什么规则接受记录，以及应用规则是否符合业务目的。比特币开发者指南介绍了节点独立验证、区块哈希连接和累计工作量选择规则；以太坊智能合约安全文档则强调权限、检查、测试与独立审查。两者分别涉及账本一致性和应用安全。
一笔操作即使符合链上规则，也可能利用了应用设计中的漏洞。系统能够一致地执行程序，并不代表程序已经准确表达了开发者的意图。
不可篡改是否意味着绝对不能改变
在比特币的机制中，历史记录的保护依赖哈希连接、工作量证明和节点验证。理解这一性质时，需要考虑重写历史的成本以及网络条件，不能把它理解成脱离条件的绝对保证。
区块高度也不适合作为全局唯一标识：分叉期间，同一高度可能出现不同区块。应用若仅按高度识别记录，就可能混淆竞争分支；引用具体区块时需要区块哈希。这里讨论的是比特币的机制，不能直接套用到所有区块链。
公开函数是否等于任何人都能管理
合约接口的可见性和操作授权是两个问题。面向外部的函数可以接收调用，但敏感操作仍需验证调用者权限。开发时应逐项明确谁能执行管理操作，以及权限如何转移或撤销。
单一管理员、角色分工和多签管理各有适用条件。角色分工有助于限定职责，多签要求多方同意；实际效果还取决于权限配置和密钥是否独立管理，不能仅凭采用某个模式就认定已经消除单点风险。
异常检查能代替完整设计吗
输入条件、调用权限与内部不变量需要分别考虑。不变量是程序执行过程中应始终成立的约束，例如某些余额关系。检查条件只有覆盖了真实业务约束，才能发挥保护作用。
开发者可以围绕每次状态变化追问：操作前必须满足什么条件，完成后必须保留什么关系，失败时哪些变化应回退。仅确认正常路径能够运行，容易遗漏边界输入和异常调用顺序。
测试和审计通过后是否就安全了
测试结论受用例覆盖范围限制，独立审查也可能漏掉缺陷。形式化验证能够证明指定模型满足指定性质，但其结论依赖规格和假设，不能扩大为整个系统不存在任何错误。
因此，评估安全性需要说明验证对象、覆盖条件和剩余边界。对于部署后难以直接修改的合约，这些问题应在上线前厘清；如果设计了升级能力，还需单独审视升级权限及其带来的信任要求。