共享记录与通信传输的边界
区块链在航天应用中的边界，首先取决于需要解决的是记录协作问题，还是通信问题。NIST IR 8202将区块链概括为分布式实现、具有篡改可察觉和抗篡改特性的数字账本；在网络正常运行条件下，已发布的交易记录不能随意改写。这为多方共享历史记录提供了技术基础，但不等于完整的航天系统解决方案。
哪些条件下可以讨论应用
如果多个参与方需要维护共同记录、核对提交历史，并且业务允许等待确认，可以评估区块链是否有价值。例如，跨组织的数据交接记录可作为候选场景，但这属于基于账本原理的适用性分析，不代表某个航天项目已经验证了效果。
评估时需要明确谁能提交记录、谁参与确认、出现错误如何处理。若单一管理方已经能够可靠维护记录，仅有“需要留痕”这一条件，还不足以说明必须引入区块链。
延迟与断连限制共识能力
RFC 9171介绍的Bundle Protocol第7版面向容迟网络，采用存储、携带和转发方式，应对间歇连接、较大或变化的延迟等通信条件。它处理数据如何跨越受限网络传送，和区块链处理共享账本状态的问题不同。
当航天通信链路存在长延迟或断连时，账本节点交换信息也会受到影响。能够暂存并转发数据，不代表节点能够立即达成一致。因此，需要及时响应的控制功能，不能仅凭区块链的抗篡改特性就认定其适用；还需独立验证通信与确认时限。
记录可靠不等于数据真实
账本保护的是已经记录的信息及其历史。若输入的数据存在测量错误或被错误提交，记录难以改写也不能证明输入真实。数据采集、提交身份和核验机制仍需单独设计。
同样，共享账本不能直接推出数据保密或链路安全。记录可由谁读取、传输如何保护、节点如何管理，都属于需要另行解决的问题。RFC 9171也明确将传输途中的安全机制和节点管理机制排除在该文档的规定范围之外。
常见问题与判断方法
是否必须让每颗卫星参与共识？不能从分布式账本的定义推出这一要求。参与节点与部署位置应根据通信条件、管理关系和业务需求确定。
用了容迟网络是否就能保证区块链正常运行？不能直接保证。传输能力只是前提之一，还需检查所选共识机制在延迟、断连和恢复连接时的行为。判断应用边界，应分别回答记录是否需要多方共同维护、确认可以等待多久，以及通信中断时业务如何继续。