先确定资料能够证明什么
区块链画册设计的资料来源如何核验，关键是建立文字、图示与证据之间的对应关系。介绍区块结构的文档，可以支持技术原理说明；它不能直接证明某个项目已经部署、运行安全或具备特定性能。核验时应先明确画册介绍的是通用概念、特定网络，还是具体项目，避免扩大证据的适用范围。
分别确认两个来源的适用范围
ethereum.org 的《Technical intro to Ethereum》介绍了以太坊的权益证明机制、EVM及智能合约，可作为解释以太坊基础概念的参考。其中，智能合约是部署到网络并由网络执行的程序，这一说明不能单独证明某个应用的代码可靠。
developer.bitcoin.org 的《Block Chain》介绍了比特币通过前一区块头哈希连接区块、使用工作量证明，以及全节点独立验证区块等机制，适合支持比特币账本结构与验证流程的说明。
两个来源分别讨论不同网络。它们可以帮助核对区块关联等共通概念，但不能相互替代，或被写成对同一项目的双重认证。
为画册中的结论保留证据位置
编辑时可为每项重要表述记录页面标题、完整网址、对应小节及支持内容。实际访问后再记录访问日期；涉及版本变化的内容，应保留可追溯的页面版本。仅有网址或摘录时，页面身份、完整上下文和更新情况仍需进一步确认。
摘录中的菜单、跳转提示和演示链接不等于技术证据。正文被截断时，应暂缓使用依赖缺失部分才能成立的结论。来源之间出现差异，也应先检查讨论对象、文档年代和适用条件。
图解必须接受同样的核验
画册里的箭头、图标和标签同样会表达技术结论。区块连接图应标明哈希引用关系，避免画成普通文件顺序排列；共识机制图应写清所对应的网络，不能将比特币的工作量证明流程直接套用于以太坊。
概念图应注明简化范围。把以太坊描述为共享的虚拟计算环境时，图形不应让读者误以为存在一台中心服务器。智能合约流程图也不能从“程序按条件执行”推导出“执行结果必然符合现实业务需求”。
常见问题与定稿条件
“有两个来源就算核验完成吗？”仍需逐项检查来源是否支持画册里的具体表述，特别是带有“所有”“绝对”“永久”等限定词的句子。
“能否直接写数据绝不可改？”更准确的解释应说明哈希关联与共识机制如何约束历史记录修改，避免省略安全条件。“基础文档能否证明项目可信？”具体项目仍需要对应的实现与运行证据；缺少这些证据时，画册应限于技术概念说明。