一、先明确市场应用的讨论范围
“区块链创建市场”可以涉及不同业务。这里讨论通过智能合约承载部分业务规则的市场应用，重点是哪些账户能够修改规则、哪些操作应被拒绝，以及如何验证合约行为。技术安全检查不能替代对完整业务流程的分析，也不能直接证明某个市场可靠。
二、公开功能是否意味着任何人都能管理
公开可调用与拥有管理权限并不是一回事。以太坊智能合约安全文档强调，敏感操作需要访问控制，不能仅凭函数可见性区分普通用户和管理员。
落实到市场设计，应先区分用户正常操作与后台管理操作。例如，若系统设有暂停功能，就需要单独明确谁能触发，而不是让所有可访问市场的账户共享管理能力。
三、一个管理员是否足够
OpenZeppelin访问控制文档区分了所有者模式与基于角色的权限管理。前者适合管理职责简单的系统；后者适合把不同职责分配给不同账户，并遵循最小权限原则。
判断标准不是账户数量，而是权限边界是否清楚。即使设置多个角色，如果同一账户掌握全部关键权限，也不能据此认定风险已经分散。多签能够增加共同确认环节，但仍需考虑签名参与方之间是否真正独立。
四、权限交接和退出为什么容易出问题
OpenZeppelin文档指出，所有权转给错误账户可能造成管理障碍；两步交接要求新所有者主动接受。放弃所有权后，受所有者权限保护的功能将无法继续调用。
因此，“取消管理员”不应被简单理解为完成安全建设。对市场应用而言，应先核对还有哪些维护职责依赖该权限，再判断交接或退出是否符合预期。
五、功能跑通为什么不等于安全
以太坊安全文档介绍了条件校验、单元测试、静态分析和模糊测试等方法。正常输入下运行成功，并不能覆盖异常输入和边界状态；形式化验证的结论也受所定义性质及模型范围限制。
市场功能测试除了检查操作能否成功，还应检查不符合条件的操作能否被拒绝。业务规则若没有写清楚，测试通过也未必意味着实现符合真实需求。
六、审计之后还需要关注什么
独立审查可以补充开发团队的检查，但审计不能保证发现所有缺陷。合约部署后，修复也受到既有设计约束，不能默认像普通网站一样直接替换代码。
上线前可围绕三项问题复核：敏感权限是否明确，异常操作是否有预期结果，实际部署版本是否属于已验证范围。安全应贯穿设计、验证和维护，而不是只依赖一次审计。