先明确要查哪一类设计文档
“疫情之下区块链应用的设计文档怎么查”并不是只搜索一个项目名称，而是先确定文档层级。协议层关注区块如何组织、交易如何确认、节点如何同步；应用层关注用户、数据、权限和业务流程；智能合约层则关注规则如何写入链上并被调用。若目标是形成项目方案，应同时查看这三类内容，避免只看概念介绍。
疫情相关应用可能涉及物资流转、检测结果协作、机构间凭证核验、捐赠记录或供应链追踪。不同场景对隐私、身份认证、数据保存和参与方权限的要求并不相同，因此不能因为使用了区块链，就直接套用某个通用架构。
两个基础资料入口怎么分工
Bitcoin 开发者指南适合作为底层机制的查阅入口。可以重点查看区块链、交易、钱包、支付处理、运行模式和点对点网络等栏目，用来理解交易如何形成记录、节点如何传播信息，以及钱包和支付流程在系统中的位置。它更适合回答“账本和网络怎样运行”这类问题。
Ethereum 技术文档适合补充可编程应用的概念。其基础说明将区块链描述为由网络中多台计算机共同维护的公共数据库，并介绍区块通过对前一区块的密码学引用形成链式关系。文档还说明，智能合约是发布到网络状态中的可复用程序，用户可以通过交易请求调用它。它更适合回答“业务规则怎样被程序化”这类问题。
查阅时可按“区块链基础—交易与账户—节点与网络—智能合约—应用框架”的顺序建立笔记。不要把 Bitcoin 的支付和账本模型直接当成所有区块链应用的实现方案，也不要把 Ethereum 的智能合约示例直接视为疫情业务已经验证的做法。
从资料整理成疫情应用设计文档
一份可读的设计文档通常应先写业务目标和适用边界。例如，系统可以记录机构之间的交接事件或凭证状态，但原始健康数据是否上链、谁有权读取、出现错误后如何更正，都需要单独规定。区块链的不可篡改特征有助于保留连续记录，却不能保证上链前输入的数据一定真实。
随后绘制参与方和数据流：哪些机构运行节点，哪些用户提交交易，哪些信息公开，哪些信息仅由授权方查看，链上保存摘要还是完整内容，链下系统如何保存敏感资料。由于区块链节点通常需要对网络状态达成一致，设计时还要说明交易确认、异常重试、节点离线和权限撤销等情况。
如果使用智能合约，应把输入、条件、状态变化和输出分别列明。例如，某次物资交接可由授权账户提交，合约检查参与方权限后记录状态变化；但身份审核、实物验收和争议处理仍可能需要链下机构完成。这样的拆分比笼统地写“利用智能合约实现可信管理”更便于评审和实施。
适用条件与不适用情况
区块链方案较适合多个相互协作但不希望由单一参与方独占记录的组织，需要共享事件顺序、责任记录或状态变化，并且能够约定参与规则和身份体系。若只有一个机构维护数据，或者业务主要是高频查询、复杂统计和实时计算，普通数据库可能更直接。
涉及个人健康信息时，应优先进行数据最小化和权限设计。可考虑把敏感原文留在受控系统，将必要的校验信息或记录摘要用于链上核验，但具体做法仍取决于法律要求、组织治理和技术测试。资料中的通用区块链原理不能证明某个疫情项目符合隐私法规或具备实际效果。
常见问题
问：查设计文档时先看 Bitcoin 还是 Ethereum？答：若关注交易、区块、钱包和点对点网络，可先看 Bitcoin 开发者指南；若关注智能合约、账户、状态变化和可编程应用，可先看 Ethereum 技术文档。最终仍应按业务目标交叉阅读。
问：把数据写入区块链就能防止疫情数据造假吗？答：不能。区块链主要帮助参与者共享并校验已经提交的记录，无法自动判断采集设备、人员或机构提交的信息是否真实。因此设计文档必须写明数据来源、审核流程和纠错机制。
问：设计文档只写智能合约代码是否足够？答：不够。还应说明参与方、身份权限、链上链下边界、节点运行方式、异常处理、隐私保护和数据生命周期。只有代码而没有治理和业务流程，通常难以支撑实际协作。