适用范围：聚焦合约型应用
讨论区块链应用市场需要注意的问题，首先要明确技术范围。本文关注以以太坊智能合约承载业务逻辑的应用，重点是安全与权限治理，不涉及市场规模或具体项目评价。Ethereum开发者安全文档强调权限限制、异常检查、组合测试和独立审查；这些措施共同构成安全基础，但不能单独保证应用没有漏洞。
管理权限是否清楚且受到约束
OpenZeppelin访问控制文档区分单一所有者和角色化授权，并强调最小权限原则；所有权交接、角色管理员和默认管理员都需要特别保护。多签可以增加敏感操作的批准门槛，两步交接则有助于降低所有权误转风险。
评估应用时，应分别看谁能操作业务、谁能分配权限、谁能改变规则。角色名称多，不代表权力已经分散；同一账户可能兼任多个角色，管理员也可能重新授予权限。真正需要检查的是最终控制关系，而非界面展示的角色数量。
公开调用与异常处理是否匹配
面向外部开放的函数，需要在合约内校验调用者、输入和业务状态。网页隐藏了某个按钮，并不等于链上操作已经受到限制。
输入校验关注请求是否符合条件，不变量检查关注系统必须始终满足的约束。两者作用不同。异常回滚能够撤销当前失败执行中的状态变化，却不是追回历史损失的通用手段。
测试与审计的结论是否被夸大
常见误区是把正常流程测试通过等同于安全。评估测试覆盖时，还应关注越权调用、边界输入以及多步操作后的状态变化。独立审计需要结合审查范围、代码版本和问题修复情况理解，不能把报告名称当成安全保证。
形式化验证也有适用边界：它针对选定模型和明确描述的性质建立证明。若业务规则遗漏，或实际部署与验证对象不一致，证明就不能自动覆盖这些差异。
不可变与可升级各有什么问题
不可变不等于不会出错，而是已部署代码的缺陷可能难以直接修补。采用升级机制的应用，则需要额外说明谁能升级、批准条件是什么，以及升级权限如何受约束。
放弃所有权也不必然更安全。它可能使受所有者权限保护的维护功能无法再调用，却不能自动证明其他角色或升级入口已经消失。判断应用的安全边界，应同时看代码约束、实际权限和维护能力，而不是只看“不可变”“已放权”等宣传措辞。