先明确：你要查的是哪一类设计文档
查资料时，不宜只搜索“区块链原理”或只看一张结构图。更稳妥的路径是先确定问题边界：如果要了解交易如何被记录，查交易、区块和账本；如果要了解节点为何接受同一条链，查验证规则和共识；如果要了解应用如何改变链上数据，查虚拟机、账户模型和智能合约。这样可以避免把某个项目的设计误认为所有区块链都采用的通用规则。
从区块与哈希理解链式账本
阅读比特币设计文档时，还应注意默克尔树。交易标识经过逐层两两组合和哈希，最终形成默克尔根，并写入区块头。验证者可以利用区块头中的默克尔根和必要的中间哈希，检查某笔交易是否属于指定区块，而不必重新接收全部交易数据。这个结构说明了区块头、交易集合和轻量验证之间的联系。
交易、节点与共识如何衔接
不同区块链的共识机制不能混为一谈。比特币开发者指南重点说明工作量证明：区块头必须满足难度目标，节点通常选择累计工作量更高的有效链。以太坊的技术介绍则说明其采用基于权益证明的机制，由验证者参与区块提议、检查和网络安全维护。因此，查阅设计文档时，应把“区块如何连接”与“节点如何选择有效历史”分开阅读。前者是数据结构问题，后者是共识问题。
以太坊文档中的状态、EVM与智能合约
智能合约是部署到虚拟机状态中的可重复执行程序。用户通过交易请求调用合约，合约根据调用参数和当前状态执行代码，并产生新的状态变化。阅读这部分设计时，应依次查看账户与交易、虚拟机、智能合约及节点文档，重点记录“谁发起请求、谁执行代码、哪些规则决定结果、结果如何提交”。这条链路比单独记忆术语更有助于理解系统。
比特币文档中的UTXO与双重支付
查阅比特币交易设计时，应将交易输入、交易输出、交易标识、手续费和区块确认放在同一张关系图中。输入必须引用可用的历史输出，输出总额不能超过输入总额，差额通常可作为包含该交易的区块所对应的费用。这个模型与以太坊以账户和全局状态为中心的表达方式不同，不能直接用一套术语替换另一套结构。
一套可执行的文档查阅顺序
做笔记时建议建立四列：对象、产生者、验证规则、最终影响。例如，“交易”由用户发起，节点验证签名和状态条件，成功后影响账户或UTXO；“区块”由参与出块的节点提出，其他节点验证其内容和链上位置，接受后成为账本历史的一部分。最后用一个完整案例回放流程，而不是只摘录概念定义。
适用条件与常见问题
常见问题一：区块链是不是只要有哈希就安全？不是。哈希能帮助发现数据变化，但账本最终如何被接受，还依赖节点验证规则和共识机制。问题二：区块高度能否唯一标识区块？在出现分叉时，多个区块可能具有相同高度，因此还需要结合区块哈希等信息。问题三：智能合约是不是自动执行且绝对正确？不是。它只是由网络按既定代码和状态执行的程序，代码逻辑、调用条件和协议限制仍决定结果。问题四：比特币和以太坊能否用同一套交易模型理解？不能。前者重点是UTXO，后者重点是账户、全局状态和虚拟机。