存储研究的三个层次
区块链存储可以从数据组织、完整性验证和记录一致性三个层次理解。数据组织决定如何保存与查询；完整性验证用于检查内容是否与已知摘要一致；记录一致性涉及节点接受哪些区块。三者相互配合，但各自解决的问题不同。
哈希、Merkle树与区块连接
比特币开发者指南描述了两种连接关系：区块内的交易通过Merkle树汇总为根哈希，区块之间通过前一区块头的哈希连接。UTXO表示尚未花费的交易输出，是验证后续支出所需的状态。
哈希提供内容摘要，不能代替原始数据存储。Merkle证明适合验证某条记录是否属于特定根所代表的数据集合，前提是根的来源可信或已经完成必要验证。包含关系本身不能证明交易符合全部规则。
前缀树、路径压缩与状态组织
以太坊的Merkle Patricia Trie说明展示了可验证键值结构：前缀树按键的路径检索，路径压缩合并连续的无分叉路径，哈希引用把节点联系到根。分支、扩展和叶子节点承担不同的组织功能，RLP用于节点序列化。
这种结构适合研究按键查询与状态证明。需要区分树中的逻辑路径和数据库中的实际查找：一次树查询可能读取多个底层节点，因此树的结构会影响读取次数与存储开销。
序列化与底层键值数据库
序列化把结构化内容转换为确定的字节表示，使不同节点能够按相同规则计算哈希。研究时必须同时关注内容与编码规则，否则看似相同的数据也可能得到不同摘要。
底层键值数据库负责保存和读取节点，树结构负责组织路径与验证关系。评估方案时，可以分别考察路径长度、节点编码大小，以及更新时需要重新处理的节点范围，不能仅凭树的名称判断性能。
共识与常见理解误区
共识规则决定哪些区块可以被接受。比特币通过工作量证明和累计工作量相关的链选择机制处理竞争分支，因此存储系统还需要考虑分支及其对应状态，区块高度不能单独充当全局唯一标识。
根哈希能恢复完整数据吗？不能，它用于核验，恢复内容仍需要相应数据。哈希是否绝对不会碰撞？其安全性依赖密码学假设，应理解为实践中难以构造碰撞。数据可验证是否意味着始终可读取？也不能，完整性证明与数据是否可获得是不同问题。