先把架构判断拆成可核验命题
区块链层次架构的研究证据怎么核验，关键是明确每项结论究竟描述什么。“系统分为若干层”可能只是研究者的分析框架；“某类客户端负责某种消息传播”则是具体实现命题。核验时应写清研究对象、功能边界和适用版本，避免仅凭相同的层名判断架构一致。
两个来源分别能支持什么
以太坊开发文档的 Networking layer 条目描述：执行客户端与共识客户端具有不同的网络协议栈，节点发现与节点间信息交换承担不同任务。这可以支持对该系统通信职责的分解，但不能证明所有区块链都采用相同分层。来源：https://ethereum.org/developers/docs/networking-layer/
比特币开发指南的 Block Chain 条目解释：全节点独立验证区块，区块通过前序区块头哈希连接，交易通过默克尔树汇总，工作量证明参与链的维护。这些内容支持分析数据组织与验证规则的关系，但不能直接证明某种通用层次模型。来源：https://developer.bitcoin.org/devguide/block_chain.html
让证据与结论逐项对应
核验记录可以包含待证命题、对应章节、适用对象、版本信息和证据缺口。引用应紧邻它所支持的判断。例如，节点发现机制只能说明节点如何寻找通信对象，不能据此推出交易有效性或共识安全性。
两个独立来源能够提供不同系统的对照，但不自动构成对同一命题的交叉验证。若研究声称某种架构提高吞吐量，还需要有明确配置、对照条件和测量方法的实验；介绍性文档本身不足以支撑性能因果结论。
适用条件与版本边界
涉及协议迁移、客户端默认行为或功能弃用时，应核对对应版本的规范与实现。材料中的“当前”不能脱离页面时间和软件版本直接沿用。正文存在截断时，缺失部分应保留为待核验内容，不能通过上下文补成确定事实。
跨项目比较应对齐功能，而非只对齐名称。数据结构、消息传播、规则验证可以作为分析维度，但是否存在独立模块、模块如何交互，需要各项目自身的证据。
常见问题：文档描述算研究证明吗
开发文档适合支持机制说明；实现是否符合描述，需要进一步检查代码或测试；运行效果与安全结论，则需要相应实验或论证。证据类型应与问题匹配。
发现来源表述过于简化或彼此不一致时，应缩小结论范围，标明争议点，再查对应规范。保留未核验状态，比把推断写成项目已经证实的事实更准确。