Substrate入门专题，目前有以下几篇文章：
关于“区块链”的块链结构这里就不再赘述，听过这个名词的应该都多少在心里能想到大概的样子。因此本文直接开始从Substrate的区块头结构开始讲解。
总体来说，Substrate的卖点就是一个区块链框架，因此实际上对于区块头，交易体等一系列区块链中的基本元素而言，都是可以自行定制的，并非是固定的结构体。然而由于区块头中含有的一些证明及一些属性与区块链的运行过程（基于状态），共识（共识证明）等方面是“强耦合”的，因此一般情况下在Substrate中使用的区块头都直接使用了Substrate默认提供的，极少有需求需要对其进行更改。
参考本系列第四篇《Substrate 入门(4) - 项目结构中的描述，应该清楚的知道，位于/bin目录下的代码属于框架外的，可以参考的，位于primitives及client里面的代码属于Substrate框架内的，一般情况下不改动的。
因此位于不同的文件夹下即是Substrate框架与用户编写代码的分界线。
总所周知，在区块链的块结构中，一个块由区块头（block_header）与该区块下的交易体共同构成。
而共识实际上共识的就是区块头，区块头就是对这个区块信息的摘要与证明。
Substrate提供了一个Header的模板，位于/primitives/runtime/src/generic/header.rs文件中：
pub struct Header<Number: Copy + Into<U256> + TryFrom<U256>, Hash: HashT> {
/// The parent hash.
pub parent_hash: Hash::Output,
/// The block number.
#[cfg_attr(feature = "std", serde(
serialize_with = "serialize_number",
deserialize_with = "deserialize_number"))]
pub number: Number,
/// The state trie merkle root
pub state_root: Hash::Output,
/// The merkle root of the extrinsics.
pub extrinsics_root: Hash::Output,
/// A chain-specific digest of data useful for light clients or referencing auxiliary data.
pub digest: Digest<Hash::Output>,
}
这里简单对这个模板做介绍：
state_root：状态根，参考本系列《Substrate 入门 - 具备状态的链 》，是对区块执行后状态变更的证明extrinsics_root：交易根，代表了该header下的区块体中交易的内容与顺序，是对区块信息的摘要digest，区块附加信息。digest翻译名“摘要”，但是这里笔者觉得这个类型更像是对区块信息的一些附加信息的集合，当前Substrate的文章及官方文档几乎都没对这个属性的剖析，但是其实它是相当重要的一个组成部分，后文会做分析。我们浏览一个模板范例bin/node中的例子：
文件/bin/node/runtime/src/lib.rs L528 左右
pub type Header = generic::Header<BlockNumber, BlakeTwo256>;
pub type Block = generic::Block<Header, UncheckedExtrinsic>; // Block 引用了上面Header的结构，UncheckedExtrinsic是交易，后续文章会介绍。因此Block中是可以看得到Header的结构，而这个结构是由用户定义了传入
L112行左右
impl frame_system::Trait for Runtime {
// ...
type Header = generic::Header<BlockNumber, BlakeTwo256>; // 可以看到这里定义runtime内部Header的结构与上面对于Header的定义是一致的。
// ...
}
我们已知 node 中是用户编写的代码，因此我们可以注意到，用户代码中的Header是可以由用户自由定义的，包括并不限于如下改动：
保留Substrate的框架内默认Header模板，即generic::Header，也就是位于/primitives/runtime/src/generic/header.rs中的定义：
BlakeTwo256）重新使用自己定义的Header
以上总结了在Substrate框架中Header的定义，可以看出，由于Substrate的框架属于状态类型的链，因此其提供的Header的模板是偏向于状态类型的定义，而且其Header类型提供的信息实际上和以太坊十分接近，不过一个很大的不同是将以太坊的收据根receipt_root移除了。
不过相对应的，Header中提供了一个新的类型digest，实际上这个类型是一个能附加很多额外信息的类型，例如对于收据根就可以附加在这里的，比如是pow的链需要提供nonce和bits这类的难度信息也可以附加到digest，除此之外其还提供了pos中出块者的签名，共识证明信息等等相当重要的信息。接下来做简单介绍。
前文已经说过，digest更像是对于该区块其他所有附加信息的一个集合，现在简要分析如下：
见文件/primitives/runtime/src/generic/digest.rs L31 行左右：
pub struct Digest<Hash: Encode + Decode> {
/// A list of logs in the digest.
pub logs: Vec<DigestItem<Hash>>,
}
我们可以看到，digest实际上是一个DigestItem的列表集合，因此可能每一个块都不同，其长度也不是固定的。因此如何解析Digest实际上是这条链的协议之一，是这条链的开发者应该重点进行设计的地方。
DigestItem的定义见 L77 行
pub enum DigestItem<Hash> {
ChangesTrieRoot(Hash),
PreRuntime(ConsensusEngineId, Vec<u8>),
Consensus(ConsensusEngineId, Vec<u8>),
Seal(ConsensusEngineId, Vec<u8>),
/// Some other thing. Unsupported and experimental.
Other(Vec<u8>),
}
由于本系列文章针对的是Substrate入门，因此本文仅对这些类型做介绍，至于如何使用这些及扩展不做详细说明。
ChangesTrieRoot：事实上是类似以太坊收据根receipt_root的一种加强版本（暂定），是对该块中每一条交易执行变更的证明，仅仅在该链genesis的时候决定是否启用。默认不启用。PreRuntime：对于部分PoS算法中必须，在Aura和Babe中用于记录轮到某个出块者出块的证明，如Aura中的slot，Babe中还会记录VRF证明等（见/primitives/consensus/babe/src/digest.rs:L44）。Consensus：对于部分PoS算法必须，用于记录共识算法中需要记录的特别的信息。如Aura/Babe中使用这个记录每个epoch验证者切换的列表。Seal：所有PoS算法必须，很多情况下用于记录这个产出这个区块的验证者的签名，因为在PoS中需要出块者使用的自己的私钥对区块进行签名，表面这个区块是由自己产出而不是别人产出。（PoW是靠难度，因此不需要签名）Other：扩展字段，因此一般对区块头的扩展都可以放在这里面，这里相当于编写链的人需要小心制定协议，如通过顺序，或者关键字等提取信息。这里可以扩展如：以上内容在编写轻节点以及区块链前端的时候相当重要，因为很多关键信息需要从Digest中解析得到（如这个区块的出块者，轻节点获取验证者变更的信息等）
这里特别强调以下对于DigestItem的编码的Encode/Decode需要遵从如下定义：
pub enum DigestItemType {
ChangesTrieRoot = 2,
PreRuntime = 6,
Consensus = 4,
Seal = 5,
Other = 0,
}
对于Encode/Decode的特点后续会写一篇文章专门描述。这里是需要提醒前端的开发者需要特别注意这个编码顺序。
以上即是对Substrate的区块头定义的介绍，这里总体注意如下几点：
Digest属性需要特别注意，很多与共识相关的信息会记录在这里。本文首发于知乎专栏金狗喵喵喵的区块链研习，版权属于@金晓。如需转载，需取得同意并标明出处，并涵盖版权信息！
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8