应用边界由业务依赖决定
区块链+项目应用的应用边界是什么，可以从三个问题理解：合约能获得什么信息，哪些账户能改变系统，以及执行结果需要谁来落实。智能合约能够按代码处理输入和权限，但业务涉及外部事实、人工判断或设备动作时，仍然需要链外机制配合。这里讨论的是通用技术边界，不代表某个具体项目已经实现相应能力。
数据边界：记录一致不等于事实准确
以太坊预言机文档说明，智能合约默认无法直接读取链外信息，预言机负责把外部数据传入链上。这使节点能够基于一致的输入执行合约，同时带来数据正确性、可用性和提供者责任问题。
例如，某项业务以天气条件为触发依据，就需要明确观测地点、统计时间和异常数据处理方式。即使各节点对同一输入得出相同结果，也不能据此证明传感器测量准确。适用条件是外部事实能够被清楚定义，并具有可核验的数据来源；存在争议的判断则需要额外的处理规则。
权限边界：自动运行仍可能包含管理权
OpenZeppelin访问控制文档介绍了所有者管理与基于角色的授权方式。不同角色可以承担不同操作，角色管理员则能授予或撤销权限；因此，管理员本身也是系统的重要信任环节。
项目需要把业务职责对应到具体权限：谁能提交信息，谁能调整授权，谁能操作关键功能。如果业务要求多人分工，仅设置一个全权账户可能无法体现这种约束。适用条件是职责能够明确划分，并且管理权限的交接、撤销和监督方式与业务要求一致。
执行边界：链上结果需要链外承接
预言机也可以向外部系统传递链上信息。不过，合约产生某个结果后，设备是否响应、服务是否交付，仍取决于外部系统。设计应用时，需要分别说明链上完成的步骤和链外负责的步骤，并为反馈缺失或执行失败安排处理机制。
常见问题：哪些能力不能直接推定
接入多个预言机是否就能保证数据真实？不能直接推定。多个节点可能依赖同一个原始来源，评估时仍需关注来源独立性、更新情况和分歧处理方式。
有权限控制是否意味着系统没有管理风险？权限检查只能限制谁可以调用功能，不能保证获授权者的每次操作都符合业务目的。
什么业务更容易界定应用范围？输入标准清楚、规则能够编码、权限责任明确、链外结果可以核验的业务，更容易确定合约承担的部分。若这些条件尚不清晰，应先厘清业务流程与责任，再决定哪些环节进入链上。