先明确范围：十大风险不是权威排名
这里的“十大风险”是理解技术安全的十个切入点，并非按发生概率或损失规模排列。NIST《区块链技术概述》强调分布式账本的篡改可察觉性与抗篡改能力；以太坊智能合约安全文档则讨论权限、代码验证和独立审查。两者分别帮助理解账本与应用的安全边界。
一、忽略共识运行前提
账本记录难以修改，以网络正常运行等条件为前提。入门时不能把抗篡改理解为任何条件下都绝无变化，也不能把一种网络的安全假设套用到所有区块链。
二、把记录一致当成事实真实
共享账本解决的是记录与一致性问题，并不自动证明输入内容符合现实。理解一条链上记录，仍需区分“系统接受了这条数据”和“数据描述的事情真实发生”。
三、管理员密钥失陷
如果管理员账户的密钥被他人控制，攻击者可能获得相应管理能力。这说明底层账本运行正常，也不代表上层应用的管理入口安全。
四、敏感操作缺少权限限制
允许外部调用合约函数，不等于允许任何人执行敏感操作。关键问题是调用者是否经过授权；函数可见性与业务权限不能混为一谈。
五、管理权过度集中
单一所有者可能成为单点故障。角色分工和多签可以减少对单个账户的依赖，但安全效果仍取决于权限划分、签名门槛及参与者之间是否真正独立。
六、输入与状态校验不完整
合约需要检查输入条件，并维护始终应当成立的状态约束。只验证正常流程，可能遗漏异常调用顺序或边界输入；自动执行并不会自动补全业务规则。
七、部署后难以修复
已经部署的合约代码通常不能像普通软件一样直接修改。不能预设发现漏洞后总能及时修补；即使存在升级机制，也要另外理解谁有升级权、可修改哪些逻辑。
八、测试覆盖造成安全错觉
单元测试通过，只说明已设计的测试场景符合预期。模糊测试、静态分析和动态分析提供不同检查视角，但仍需要明确要保护的安全属性。
九、把形式化验证理解为全面保证
形式化验证针对规定的模型和性质建立证明。若规格遗漏业务要求，证明成立也不能说明实际系统不存在其他问题；验证结论必须连同适用范围一起理解。
十、把审计当作永久免责证明
独立审查有助于发现开发阶段遗漏的问题，但不能保证找出全部漏洞。理解审计结论时，需要关注它检查了什么，以及当前代码与被检查版本是否一致。
常见问题与适用条件
所有区块链都有上述风险吗？不完全相同。共识与账本边界适用于一般概念讨论，合约权限、升级和代码测试则主要适用于具有相关功能的应用。
去中心化是否意味着不再需要信任？不能简单这样理解。信任可能转移到代码、管理权限和验证流程。抗篡改、自动执行与安全审查各解决不同问题，不能相互替代。