先看哪些代码和数据受到隔离
讨论区块链 可信执行环境时，应先问受保护的对象是什么。Intel对SGX的介绍将重点放在使用中的数据，以及应用中选定代码和数据的隔离保护。开发者可以把相应部分放进飞地，也就是隔离运行区域。这不表示只要服务器支持某项硬件功能，整个应用的每个环节就自动进入同一保护范围。
隔离与远程证明回答不同的问题：前者关注运行区域的保护，后者帮助外部一方判断面对的环境是否符合要求。Intel将远程证明放在向飞地共享数据之前介绍。因此，阅读项目方案时要先找运行边界，再找对外提供何种证明，不能只凭一个芯片型号替代两部分说明。
产生证据和评估证据是两项职责
RFC 9334是2023年发布的资料性架构说明，并非某条链的完整通信协议。它将产生证据的角色称为Attester，将评估证据的角色称为Verifier。证据可以包含目标环境的配置、测量值或运行状态等声明；提供了一份证据，并不等于已经取得符合某套要求的结论。
验证方结合证据、参考值、背书材料和证据评估策略，形成证明评估结果。这里的判断有明确依据，而不是只检查文件能否打开。例如，某项配置是否落在允许范围内，需要对应策略；换一套适用条件，结果也可能不同。记录时应把原始证据和验证方输出分开保存，避免把两者混称为一个证明文件。
业务放行由依赖方作出决定
架构中的Relying Party可理解为依赖证明结果的一方。它接收验证方的结果，再按照自己的策略决定是否提供数据或允许某项操作。因此，验证方给出正面结果，仍可能不满足具体业务的准入条件。RFC中的例子指出，企业不一定愿意允许同一厂商生产的所有健康设备接入自己的网络。
这也不是要求必须部署三台机器或聘用三家公司。RFC明确允许一个实体承担多个角色；角色划分是为了说明谁产生什么、谁判断什么。即使验证与业务放行放在同一台服务器，方案仍应交代证据评估规则和业务接受规则，不能因为部署合并就省略其中一项责任。
证明时点与链外事实需要另外核对
假设某服务在隔离区域中汇总一组链外数量，再将摘要交给链上程序。证明环境符合策略，与证明最初录入的数量真实，是两项不同判断。这个例子只是说明信任边界：如果证据描述的是运行环境，就不能把结论扩大为每条外部业务记录都正确，还需要说明输入从哪里来、如何核对。
证明还具有时间范围。RFC指出，环境或评估策略可能在证据生成后变化，新鲜程度由接受方的策略判断；即便使用随机挑战，声明中的值也可能更早已经产生。阅读一份结果时，应区分状态测量、证据生成、结果评估和业务使用的时点。把结果摘要写入链上，不会自动更新这些时点，也不能将一次通过解释为以后持续符合条件。