区块头里有什么？每个字段的含义 图 1
区块头里有什么？每个字段的含义 · 图 1

结论先说

区块头（block header）是区块的”摘要骨架”：几十个字段的固定结构，包含”这个区块说了什么”的全部可验证承诺——父块引用、交易/收据/状态的 Merkle 根、gas 参数、时间戳、提议者、共识层数据。区块 = 头 + 交易列表（+ 叔块引用等历史字段，PoS 后简化）。轻客户端只同步头，就能验证”链的连续性与合法性”（头里的根哈希 + 共识签名），需要具体数据时再用 Merkle 证明按需取——“头即承诺集”是理解链上数据可验证性的入口。

字段逐个过（执行层头）

一，parentHash：父块头哈希——“链”的链接字段（每块指向父块，从创世块串成链）；重组时”换父”就是”从某点开始接另一条父链”。二，stateRoot：该块执行完的世界状态根（Patricia Trie 根）——“这块之后全链长什么样”的单一承诺；轻客户端验证”状态连续”（块 N 的 stateRoot 与块 N-1 的 + 本块交易的执行效果一致——全节点本地重算，轻客户端信任共识层的”头合法”）。三，transactionsRoot：交易列表的 Merkle 根——“这块包含哪些交易”的承诺（验证”某交易在这块里”用一条 Merkle 证明）。四，receiptsRoot：收据树的根——“执行结果”的承诺（验证”某交易成功/失败 + 日志”）。五，logsBloom（历史字段，日志布隆过滤器）：日志的”可能存在”快速过滤（PoS 后部分客户端简化其作用）——“这块有没有 X 类型日志”的粗筛，精确仍需收据。六，gas 参数：gasLimit（块 gas 上限）+ gasUsed（实际用量）——“这块的计算量”。七，baseFee（EIP-1559）：本块基础费——“进块门票价”（由父块填充率推导）。八，timestamp：秒级时间戳（提议者声明，共识层约束其单调/合理范围）。九，extraData/提议者地址：区块构造者身份（PoS 下与共识层的提议者对应）。十，mixHash/nonce（PoW 遗产字段）：PoS 后保留结构但语义停用（历史兼容）——看到它们别按 PoW 理解。

共识层数据：PoS 头的”附加项”

Merge 后，执行层头嵌入共识层字段：beaconRoot（最近的 beacon 块头的承诺——“执行层锚定共识层”的字段，合约可通过预编译读取，跨层验证的基础）、RANDAO reveal（提议者的随机数贡献——区块随机性的来源之一）、withdrawalsRoot（验证者提现列表的根，提现机制启用后）、以及 beacon 提议者信息。含义：执行层区块的”合法性”不再自足——它要同时满足”执行规则（头字段自洽 + 交易合法）+ 共识层接受（beacon 验证者的 attestation/提议）“。两层数据互相锚定（执行头嵌 beaconRoot，beacon 头嵌执行状态根）——“以太坊是一个状态机 + 一个共识层”的结构在头字段里直接可见。

为什么”只有头”就够验证合法性

轻客户端的验证闭环：一，头链连续（parentHash 串联 + 时间戳合理）；二，共识层签名（sync committee/attestation 聚合签名验证”这些头被共识接受”——见同步委员会专题）；三，头内承诺自洽（各根哈希格式/规则合法）。通过这个闭环，轻客户端知道”这条链是共识接受的、连续的”——它不需要交易内容/状态数据（要某笔交易时：向任意服务方要”交易 + Merkle 证明”，本地用 transactionsRoot 验证”它真的在这块里”；要某余额时：要”状态 + Merkle 路径”，用 stateRoot 验证）。分工：共识信任 = 头 + 签名（自持），数据获取 = 服务方 + Merkle 证明（外包但可验证）——“信任最小化”的具体形态就是这套头字段 + 证明结构。

开发者/用户的接触面

用户：浏览器显示的”块详情”就是头字段 + 交易列表的展示；“这块 gas 用了多少”（gasUsed/limit）、“基础费多少”（baseFee）、“谁提议的”——都是头字段。开发者：一，区块头作为”时间锚”（timestamp 的精度/单调性是 DApp 设计约束——“块时间”不是精确时钟，时间敏感的逻辑要留容差）；二，beaconRoot/预编译（合约读”共识层最新状态”的原语，跨层验证设计用它）；三，gas 参数（块级 gasLimit 调整是协议参数，单交易的 gasLimit 是交易字段——两个”gasLimit”层级不同）；四，RANDAO（区块随机性——链上”公平随机”的来源与局限：提议者有选择偏差（他选哪个 reveal），“链上随机”是”可验证的伪随机”不是真随机，敏感场景（抽奖/NFT 随机）要理解这个偏差）。

常见误读

“区块头 = 区块”——头是骨架（承诺集），区块 = 头 + 交易列表（+ 叔块等）；“轻客户端同步头 = 拥有链”——它拥有”链的合法性视图”，不拥有”数据”（数据靠证明按需取）；“timestamp = 精确时间”——它是提议者声明 + 共识约束的”块序号式时间”（秒级、有容差），不是物理时钟同步；“mixHash/nonce 还在工作”——PoS 下这两个字段是结构占位（PoW 遗产），随机性来自 RANDAO + 信标层机制。

风险提示

头字段结构是执行规范的一部分（字段集合随升级增减——如 withdrawalsRoot 的引入、历史字段的语义变化），引用以规范当前版本为准；“头合法”的验证依赖共识层签名机制的实现质量（轻客户端代码）——机制设计与实现质量是两个维度。本文为结构解释，不构成对任何客户端/浏览器/服务的评价；轻客户端的信任模型（“共识自持 + 数据外包”）在使用移动钱包/嵌入式验证时值得理解——它决定”你信任了什么、验证了什么”。

小结

一句话记忆：区块头 = 承诺集（父哈希串链、三个 Merkle 根绑住交易/收据/状态、gas/baseFee 定价格、时间戳与提议者定位、beaconRoot 锚共识层）；轻客户端”只有头 + 共识签名”即可验证链的合法性，具体数据用 Merkle 证明按需取。读区块详情时按”承诺 - 身份 - 价格 - 共识锚”四组理解字段，头结构就清晰了。