一、元数据是一种理解方式，而非统一字段
理解区块链元数据，可以先区分“记录了什么”和“如何描述、组织与验证这些记录”。交易属于区块承载的内容；区块编号、父区块引用以及数据摘要，则帮助节点定位区块、建立关联并检查一致性。
“元数据”不是所有区块链共同采用的固定字段名称。阅读具体结构时，应以网络、协议层和字段定义为准，不能把某条链的字段表直接套用到另一条链。
二、从比特币理解区块头与默克尔根
比特币开发者指南介绍了区块头与交易数据的分工：区块头包含前一区块头的哈希及交易默克尔根等信息。交易标识经过逐层组合与哈希计算，最终形成一个根哈希。
区块高度表示区块在链上的位置，但分叉时不同区块可能具有相同高度，因此高度不是全局唯一标识。默克尔证明则可结合区块头中的根哈希，核验一笔交易是否被该区块收录。
三、从以太坊理解时隙与执行载荷
以太坊区块文档区分了共识相关结构与执行载荷。slot 表示时隙，proposer_index 标识提议者，parent_root 引用父区块；execution_payload 承载交易等执行相关数据。时隙可能没有区块，因此不能把时隙编号直接当作执行层区块编号。
执行载荷中的 gas_limit 表示区块允许的 Gas 上限，gas_used 表示实际消耗量。Gas 衡量执行资源消耗，不等于数据字节数；讨论区块容量时，需要先说明采用哪种计量方式。
四、哈希、父哈希和根哈希如何区分
这些术语都涉及哈希，但回答的问题不同：区块哈希用于标识区块，父哈希用于说明它接在哪个区块之后，根哈希则概括某一组结构化数据。阅读字段时，先问“它对什么数据计算”，比只看名称更可靠。
根哈希不是完整内容的压缩包，不能仅凭根哈希还原全部交易或状态。它主要提供核验依据；要查看具体内容，仍需取得相应数据。
五、同名字段为什么不能直接比较
以 state_root 为例，必须结合它所在的结构理解。共识层状态与执行层交易处理后的状态不是同一对象，即使字段名称相同，也不代表哈希输入相同。
比较两份区块数据时，应先确认它们属于哪个网络、哪个协议层以及哪种数据结构。否则，看似对应的编号、时间或状态摘要，可能实际描述不同对象。
六、常见问题：摘要一致是否代表一切可信
交易被收录，不等于所有验证问题都已解决。证明交易属于某个区块，与检查交易执行、区块有效性和链的共识状态，是不同层面的判断。
同样，哈希关联让数据修改能够被核验发现，但不能单凭“存在哈希”就断言历史绝对不可改变。理解区块链元数据的实用顺序是：先确定字段所属结构，再确认它描述的对象，最后明确它能证明什么、不能证明什么。