Substrate 入门(5)- 区块头

1909次阅读  |  发布于4年以前

Substrate入门专题,目前有以下几篇文章:

关于“区块链”的块链结构这里就不再赘述,听过这个名词的应该都多少在心里能想到大概的样子。因此本文直接开始从Substrate的区块头结构开始讲解。

总体来说,Substrate的卖点就是一个区块链框架,因此实际上对于区块头,交易体等一系列区块链中的基本元素而言,都是可以自行定制的,并非是固定的结构体。然而由于区块头中含有的一些证明及一些属性与区块链的运行过程(基于状态),共识(共识证明)等方面是“强耦合”的,因此一般情况下在Substrate中使用的区块头都直接使用了Substrate默认提供的,极少有需求需要对其进行更改

Substrate核心与用户自定义模块的分界-目录

参考本系列第四篇《Substrate 入门(4) - 项目结构中的描述,应该清楚的知道,位于/bin目录下的代码属于框架外的,可以参考的,位于primitivesclient里面的代码属于Substrate框架内的,一般情况下不改动的。

因此位于不同的文件夹下即是Substrate框架与用户编写代码的分界线。

区块头

总所周知,在区块链的块结构中,一个块由区块头(block_header)与该区块下的交易体共同构成。

共识实际上共识的就是区块头,区块头就是对这个区块信息的摘要证明

Substrate的区块头

1. 框架内

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>,
}

这里简单对这个模板做介绍:

2. 框架外

我们浏览一个模板范例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的定义,可以看出,由于Substrate的框架属于状态类型的链,因此其提供的Header的模板是偏向于状态类型的定义,而且其Header类型提供的信息实际上和以太坊十分接近,不过一个很大的不同是将以太坊的收据根receipt_root移除了。

不过相对应的,Header中提供了一个新的类型digest,实际上这个类型是一个能附加很多额外信息的类型,例如对于收据根就可以附加在这里的,比如是pow的链需要提供nonce和bits这类的难度信息也可以附加到digest,除此之外其还提供了pos中出块者的签名,共识证明信息等等相当重要的信息。接下来做简单介绍。

digest 的介绍

前文已经说过,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入门,因此本文仅对这些类型做介绍,至于如何使用这些及扩展不做详细说明。

以上内容在编写轻节点以及区块链前端的时候相当重要,因为很多关键信息需要从Digest中解析得到(如这个区块的出块者,轻节点获取验证者变更的信息等)

这里特别强调以下对于DigestItem的编码的Encode/Decode需要遵从如下定义:

pub enum DigestItemType {
    ChangesTrieRoot = 2,
    PreRuntime = 6,
    Consensus = 4,
    Seal = 5,
    Other = 0,
}

对于Encode/Decode的特点后续会写一篇文章专门描述。这里是需要提醒前端的开发者需要特别注意这个编码顺序。

总结

以上即是对Substrate的区块头定义的介绍,这里总体注意如下几点:

  1. Substrate的区块头是可以自由定义的,但是一般情况下应该沿用模板,除非有充足的理由去改变它
  2. Substrate的区块头是偏向“状态链”的定义
  3. Substrate的Digest属性需要特别注意,很多与共识相关的信息会记录在这里。

本文首发于知乎专栏金狗喵喵喵的区块链研习,版权属于@金晓如需转载,需取得同意并标明出处,并涵盖版权信息!

Copyright© 2013-2019

京ICP备2023019179号-2