适用范围与安全重点
区块链设备和应用需要注意哪些问题，可以从设备保存什么密钥、账户拥有什么权限、合约允许哪些操作三个层面理解。以下原则适用于涉及密码密钥管理的设备和应用；合约部分主要针对以太坊智能合约，不代表某款设备或应用已经通过安全验证。
NIST SP 800-57第一部分讨论密钥材料的保护、管理与安全规划；以太坊开发者安全文档侧重合约访问控制、测试和独立审查。两者分别覆盖密钥和应用逻辑，不能互相替代。
设备侧：明确密钥保护与恢复责任
密钥管理需要考虑保密性、可用性、备份、恢复以及泄露后的处置。对保存或使用密钥的设备，应明确谁能访问密钥、备份由谁保管、设备损坏后如何恢复，以及发现泄露后如何停止依赖原有密钥。
备份与保密需要同时设计：没有可用的恢复机制，设备故障可能导致授权能力丢失；备份保护不足，则可能增加密钥暴露的机会。恢复流程还应限制操作权限，避免让恢复入口成为绕过正常保护的通道。
应用侧：将敏感权限分开管理
公开可调用的合约函数需要另行检查操作权限。函数能够被调用，并不意味着调用者应当获准修改关键状态。设计时应逐项明确敏感操作的授权条件。
角色划分可以把不同管理职责分开，多签机制则要求多个签名共同批准操作。两者解决的问题不同：多个管理员账户不自动等于多人共同批准，也不能保证消除所有单点风险，还需检查每个角色实际拥有的权限。
部署前：验证异常路径与关键约束
合约检查应覆盖输入条件、调用者身份与关键状态约束，并在条件不满足时拒绝相关操作。测试除了验证正常功能，还应关注边界输入和异常执行路径。
以太坊安全文档介绍了单元测试、静态分析、模糊测试、形式化验证及独立审查。实践中应让这些方法互相补充。形式化验证的结论取决于所用模型、规格与假设，不能直接推导出整个应用没有任何漏洞。
常见问题：审计之后是否可以放心
审计提供额外的独立检查，但不能保证发现全部问题。评估审计结论时，需要确认覆盖的代码版本和范围；后续修改也需要相应验证。
合约部署后的修复能力取决于设计。不可变代码通常无法直接打补丁；设有升级或暂停功能的系统，则需要保护这些管理权限。因此，安全工作还应明确异常处置责任和可用的应急措施，不能只停留在上线前检查。