先明确区块链能够解决什么
区块链概念场景设计的应用边界是什么，首先要看业务需要解决哪一类问题。NIST《区块链技术概述》将区块链描述为分布式实现、具有篡改可察觉性和抗篡改能力的数字账本。这意味着它主要支持共同记录与核验，不能直接承担现实事实调查。
设计场景时，应明确哪些参与方需要共享记录、哪些状态变化需要共同确认。如果需求只是单一机构保存内部信息，应先比较普通数据库是否已经足够，不能仅凭“需要留痕”就认定必须上链。
记录可信与事实真实之间的边界
一条记录难以被事后改动，并不代表它在录入时就正确。例如，在假设的货物交接场景中，账本可以保存提交的交接信息，但货物是否实际到达、检测结果是否准确，仍依赖链外采集与验证。
因此，场景设计应分别说明记录由谁提交、事实由谁核验、错误如何处理。将这些责任全部归结为“区块链保证真实”，会超出共享账本的能力范围。
智能合约与外部数据之间的边界
以太坊预言机文档说明，智能合约默认无法直接访问链外信息，预言机可将外部数据提供给合约使用。接入后仍需关注数据正确性、可用性以及提供者的责任和激励。
这要求设计者明确数据源、更新条件和分歧处理规则。例如，天气条件触发的自动处理流程，需要先定义采用哪个地区、哪个时段的观测值；数据过期或来源冲突时，也要有明确处置方式。链上执行规则一致，并不能消除输入数据的不确定性。
链上触发与现实执行之间的边界
链上状态可以经由外部系统触发设备或业务操作，但现实动作仍依赖相应系统正常工作。假设合约触发智能锁开锁，链上记录本身不能证明锁已成功打开。
涉及现实交付的场景，应区分触发请求、接收确认和完成反馈，并说明失败由谁处理。自动化能够覆盖的范围，取决于这些环节是否具备可验证的输入和反馈。
适用条件与常见问题
较适合进一步评估的场景，是多方确有共享账本需求、状态变化规则清楚、外部数据来源可说明，并且异常处理责任明确。概念方案应把这些条件写清楚，再判断区块链在其中承担什么功能。
上链后是否无需信任？仍需审视数据提供者和链外执行者。采用多个预言机是否必然可靠？还要看它们是否依赖同一数据源以及如何处理分歧。业务流程是否都能写进合约？只有能被明确表达、并有足够数据支持判断的部分，才具备自动执行的基础。