误区一：上链就等于拥有真实世界数据
智能合约通常只能直接读取区块链上的状态和交易数据。现实世界的天气、比赛结果、价格或设备状态等链下信息，不能凭空出现在合约中，需要通过预言机等机制传入链上。预言机负责从链下来源获取、整理并提交数据，使合约能够依据这些信息执行。
因此，“数据已经上链”只说明数据被记录在链上，并不自动证明它来自正确来源，也不代表提交过程没有被篡改。设计应用时，应明确数据来源、采集方式、更新频率以及多次报告出现差异时的处理规则。
误区二：使用预言机后就完全不需要信任
预言机解决了区块链与外部环境之间的信息连接问题，同时也引入了预言机问题。合约执行结果依赖外部数据的正确性、完整性和及时可用性。如果来源错误、接口失效、数据停止更新，或者提交者提供了不准确的信息，合约仍可能按照错误输入执行。
评估预言机时，至少要关注三个方面：数据是否来自预期来源并保持完整，应用请求时是否能够持续取得数据，以及提交者是否具有可追责和获得正确激励的机制。采用多个来源或多个报告者可以用于处理单一来源的风险，但具体方案仍需结合业务对时效性、准确性和成本的要求。
误区三：区块链应用天然就是完全去中心化
智能合约的执行可以由网络节点按照相同输入得到一致结果，但合约之外仍可能存在链下节点、数据服务、管理账户和运维系统。预言机服务通常同时包含链上合约与链下组件；访问控制则决定谁可以铸造资产、冻结转账、修改配置或执行其他管理操作。只看合约代码所在的链上地址，无法完整判断一个应用的实际控制结构。
应用说明应区分哪些部分由合约自动执行，哪些数据由外部服务提供，哪些关键功能由管理账户或角色触发。这样才能准确理解系统的信任边界，避免把“代码上链”误解为所有环节都不需要管理。
误区四：只设置一个管理员就足够安全
单一所有者模式适合权限简单、管理主体明确的合约，但如果系统包含铸造、销毁、暂停或参数调整等不同功能，让同一个账户拥有全部权限会扩大单点风险。基于角色的访问控制可以将权限拆分为不同角色，例如分别管理铸造和销毁，并按照最小权限原则限制每个账户能够执行的操作。
权限设计还要考虑角色的授予、撤销和管理员关系。默认管理员通常能够管理其他角色，因此需要特别保护。所有权转移也应核对新账户是否能够与合约交互；在适用场景下，两步转移、延迟操作或多签管理可以降低误操作风险，但具体选择取决于应用的治理流程和恢复能力。
适用条件与常见问题
如果应用只使用链上数据，通常不需要为外部信息单独设计预言机；一旦合约依赖链下数据，就应把数据来源、报告机制和异常处理纳入安全设计。若应用存在可改变系统状态的管理功能，则应明确角色边界、管理员权限和权限变更记录。
常见问题一：多个预言机报告不一致怎么办？应在需求阶段规定筛选、聚合或拒绝异常数据的规则，不能等到冲突发生后再临时处理。常见问题二：怎样确认谁拥有某个角色？角色可能动态授予或撤销，可以通过权限变更事件进行链下追踪；如果业务要求直接在链上枚举角色成员，则需要采用支持枚举的相应访问控制扩展。
常见问题三：权限越多是否越安全？权限拆分有助于限制单个账户的影响范围，但也会增加管理复杂度。角色数量、管理员层级和变更流程应与实际业务匹配，并在部署前验证关键功能是否可能因权限配置错误而无法调用。