一、先区分保存、检索与验证
讨论区块链和存储涉及哪些技术概念，可以从三个问题入手：数据如何持久保存，如何按标识找到数据，以及如何检查数据是否与认可的记录一致。数据库主要承担保存与读取工作，树形结构组织查询路径，密码学哈希则帮助建立可验证的关联。这些功能相互配合，但不能彼此替代。
二、哈希、区块链接与Merkle树
比特币开发者指南介绍，交易哈希经过逐层组合形成Merkle根，根值写入区块头；区块头还包含前一区块头的哈希，将区块连接起来。节点独立验证区块，并依据共识规则维护账本。比特币用未花费交易输出，即UTXO，表示仍可用于后续交易的输出。
哈希可以理解为数据的固定长度摘要，但不是可还原原文的压缩文件。Merkle树把许多数据项与一个根值联系起来，使验证某项数据时不必获取整个数据集合。其安全性依赖哈希函数的密码学性质，不能把“难以构造碰撞”解释为数学上绝无碰撞。
三、键值数据库与Merkle Patricia Trie
以太坊开发者文档介绍的Merkle Patricia Trie，将按键路径检索的前缀树与哈希验证结合，并通过路径压缩减少冗余层级。结构包含分支、扩展和叶子节点；节点使用RLP序列化，较短节点可以内嵌，较长节点通过哈希引用。文档区分了状态根、交易根和收据根，它们对应不同的数据集合。
这里有两层“键值关系”：逻辑树表达业务键到值的映射，底层数据库保存树节点。沿树查找一个值，可能需要多次读取数据库。因此，数据库的一次键查询，不等于完成一次树路径查询。
四、序列化与内容寻址
序列化是把结构化数据转换为确定的字节表示。参与哈希计算前，各方必须遵循相同的编码规则，否则即使认为数据含义相同，也可能得到不同摘要。
内容寻址使用内容计算出的标识引用数据。取回内容后，可以重新计算哈希并核对标识。这适合检查内容完整性，但标识本身不保存完整内容，也不能保证网络中始终有人提供对应数据。
五、证明的适用条件与边界
Merkle证明适用于核验某项数据是否被特定根值承诺，前提是验证者已经通过适当方式确认根值可信。若根值也由未经验证的同一方提供，证明只能说明内部对应关系，不能独立建立可信依据。
交易包含证明、交易有效性验证和共识判断不是同一件事。前者回答“是否被收录”，后两者还涉及规则执行与被认可的历史，不能仅凭一条树路径全部完成。
六、常见问题：有根哈希就够了吗
只有根哈希，不能恢复完整账本，也不能直接读取任意账户或交易；仍需要相应数据或证明。哈希关联让修改更容易被发现，共识机制则约束网络接受哪一份历史。因此，理解区块链存储，应同时关注数据可获取性、查询结构、完整性证明和共识规则，而不是把它简单理解为“多个节点各存一份文件”。