适用范围：风险不一定来自新技术
讨论“区块链新的风险有哪些常见误区”，不能把应用变化都理解成新型漏洞。本文聚焦以太坊智能合约及访问控制，不涵盖所有区块链风险，也不判断具体项目是否安全。权限集中、逻辑缺陷和验证不足，都可能在不同应用中出现。
误区一：不可篡改意味着代码可靠
Ethereum.org 的智能合约安全说明强调，部署后的代码往往难以直接修补，测试与独立审查也各有局限。不可篡改保障的是既定逻辑持续执行；如果逻辑本身有错，错误同样可能持续生效。
因此，理解安全性需要分别考虑规则是否正确、谁能执行敏感操作，以及出现异常后能否处理。不能仅凭“运行在链上”推断应用可靠。
误区二：通过审计就没有漏洞
审计提供额外检查机会，其结论受到检查范围、代码版本和前提条件约束。功能测试通过，只能说明相应测试覆盖的情形符合预期，不能代表所有输入与调用组合都安全。
形式化验证也需要明确边界：证明针对模型和指定性质成立，并不自动覆盖遗漏的需求或模型之外的依赖。讨论验证结果时，应先看它究竟验证了什么。
误区三：多角色或多签自动消除集中风险
OpenZeppelin 的访问控制文档区分单一所有者与角色管理，并指出默认管理员能够管理其他角色，也能管理自身角色。角色数量增加，并不必然意味着实际控制权分散。
理解权限结构，既要看谁能执行操作，也要看谁能授予或撤销权限。多签可以提高敏感操作的授权门槛，但效果取决于签署方是否独立、密钥是否分开保管；多个地址由同一主体控制，仍可能存在共同失效风险。
误区四：放弃所有权一定更安全
在 OpenZeppelin 的 Ownable 机制中，放弃所有权会使仅限所有者调用的功能无法继续使用。这个动作可能减少特定管理权限，也可能使必要的管理功能失效。
它的适用性取决于合约设计。若系统还有其他角色或授权路径，仅凭所有者地址的变化，无法判断整个系统的控制权状态。
常见问题：怎样理解安全机制的作用
公开函数是否意味着任何人都能完成敏感操作？不一定。公开可调用与获准执行是两个层面，实际执行还可以受到身份、输入和状态检查的限制。
采用成熟组件是否足够？组件提供基础机制，应用仍需正确配置权限并连接业务逻辑。评价安全性时，应把代码行为、授权关系和验证范围结合起来，避免把某一个机制当作整体安全结论。