适用范围：聚焦智能合约层
讨论以太坊区块链技术需要注意哪些问题，应先区分底层网络与应用合约。这里重点说明智能合约的开发和管理风险，不涵盖节点运维等全部议题。Ethereum 开发者安全文档强调，链上代码部署后的修复存在约束，应把访问控制、异常检查、多种测试和独立审查纳入开发过程。
区块链能够按规则执行代码，不代表业务规则天然正确。评估合约时，需要分别确认程序是否符合设计，以及设计本身是否允许越权或不合理的状态变化。
权限设计：明确谁能执行敏感操作
公开可调用的函数不等于任何人都应有权完成其中的操作。涉及增发、暂停或升级时，需要在合约内核验权限，不能仅靠界面隐藏按钮。
OpenZeppelin 的访问控制文档区分了单一所有者与角色管理：Ownable 适合单一管理主体，AccessControl 用于细分权限；所有权可通过两步交接确认，默认管理员则需要特别保护。多签可以提高敏感操作的授权门槛，但不能修复业务逻辑漏洞。
选择权限模型应依据职责，而非角色数量。若多个角色最终都受同一个高权限账户控制，形式上的分工并未消除集中管理风险。检查范围还应包括谁能授予权限、撤销权限和更换管理员。
异常处理：区分输入条件与内部约束
require 和 revert 可用于拒绝不符合要求的调用；assert 用于检查内部应始终成立的性质。它们的作用取决于检查条件是否完整，不能因为使用了这些机制就认定合约安全。
例如，检查调用者有权限与检查操作数量合理，是两类不同约束。审查时应把身份、输入、当前状态和执行后的业务约束分别列清，避免只验证其中一项。
验证流程：测试通过不等于没有漏洞
单元测试适合检查已知场景，但容易遗漏边界情况。静态分析、模糊测试和独立审查可以补充不同视角。形式化验证的结论也受模型、规格及假设限制，不能泛化为整个系统绝对安全。
验证目标应具体到业务性质，例如未授权账户不能修改关键参数。代码或权限配置发生变化后，还应确认已有测试和审查结论是否仍适用。
常见问题：权限越少就一定越安全吗
不一定。撤销所有权可能让受所有者保护的管理功能无法再调用；交接到错误地址也可能造成管理失效。因此，降低权限前需要确认后续维护需求与接收方的控制能力。
安全审计同样不是永久保证。更合理的判断方式是查看审查覆盖了哪些代码和配置、问题是否修复，以及实际部署是否与被审查版本一致。