Hello World

以太坊黄皮书

admin 2019年09月05日

写在篇头

本文是对以太坊的黄皮书的解析，并参照 go-ethereum 中的实现，将相应的代码也列了出来。黄皮书中使用了大量的公式将以太坊的一些流程和状态都公式化了。看不看得懂公式对理解的影响不大。本文中对公式进行了解析。嫌麻烦的可以跳过每部分公式解析的部分。

一、区块链范型

以太坊本质是一个基于交易的状态机（transaction-based state machine）。其以初始状态（genesis state) 为起点，通过执行交易来到达新的状态。

σ t + 1 \equiv Υ (σ t, T) (1)

$\begin{equation} {\sigma}_{t+1} \equiv \Upsilon(\boldsymbol{\sigma}_{t}, T) \tag{1} \end{equation}$

公式 1 表示 t + 1 时的状态，是由 t 时的状态经过交易 T 转变而来。转变函数为 $\Upsilon$ 。

如下图所示

Transaction Function $\begin{equation} \boldsymbol{\sigma}_{t+1} \equiv {\Pi}(\boldsymbol{\sigma}_{t}, B) \tag{2} \end{equation}$

B \equiv (. . ., (T 0, T 1, . . .)) (3)

$\begin{equation} B \equiv (..., (T_0, T_1, ...) ) \tag{3} \end{equation}$

Π (σ, B) \equiv Ω (B, Υ (Υ (σ, T 0), T 1) . . .) (4)

$\begin{equation} \Pi(\boldsymbol{\sigma}, B) \equiv {\Omega}(B,{\Upsilon}(\Upsilon(\boldsymbol{\sigma}, T_0), T_1) ...) \tag{4} \end{equation}$

公式 2 - 4 是从区块的角度来描述状态的转化过程。公式 2: t+ 1 时的状态，是由 t 时的状态经过区块 B 转变而来。转变函数为 ${\Pi}$ 。

公式 3: 区块 B 是包含了一系列交易 T 的集合。

公式 4: 区块的状态转变函数 ${\Pi}$ ，相当于逐条的执行交易的状态转变 $\Upsilon$ ，然后完成所有交易转变后再经过 ${\Omega}$ 进行一次状态转换。（这个地方 ${\Omega}$ 实际上是给矿工挖坑奖励。）

在以太坊中的实际情况就是区块验证和执行的过程。

逐一的执行交易（也就是使用交易转变函数操作 $\Upsilon$ 状态集）。实际就是交易比方是 A 向 B 转 10ether，则 A 账户值 -10，B 账户值 +10。（当然执行过程中还有 gas 消耗，这个后面详述）
等整个 block 交易执行完毕后，需要对矿工进行奖励。也就是需要使用 ${\Omega}$ 进行一次状态转换。
1.1 货币

以太坊中有以下四种单位的货币。以太坊中的各种计算都是以 Wei 为单位的。 （看有的地方好像有更多种单位，我这边是直接按照黄皮书走的）

Multiplier	Name
10⁰	Wei
10¹²	Szabo
10¹⁵	Finney
10¹⁸	Ether

1.2 分叉

以太坊的正确运行建立在其链上只有一个链是有效的，所有人都必须要接受它。拥有多个状态（或多个链）会摧毁这个系统，因为它在哪个是正确状态的问题上不可能得到统一结果。如果链分叉了，你有可能在一条链上拥有 10 个币，一条链上拥有 20 个币，另一条链上拥有 40 个币。在这种场景下，是没有办法确定哪个链才是最”有效的“。不论什么时候只要多个路径产生了，一个”分叉“就会出现。为了确定哪个路径才是最有效的以及防止多条链的产生，以太坊使用了一个叫做“GHOST 协议 (GHOST protocol.)”的数学机制。

简单来说，GHOST 协议就是让我们必须选择一个在其上完成计算最多的路径。一个方法确定路径就是使用最近一个区块（叶子区块）的区块号，区块号代表着当前路径上总的区块数（不包含创世纪区块）。区块号越大，路径就会越长，就说明越多的挖矿算力被消耗在此路径上以达到叶子区块。

二、区块、状态与交易

2.1 世界状态

以太坊中的世界状态指地址 (Address) 与账户状态 (Account State) 的集合。世界状态并不是存储在链上，而是通过 Merkle Patricia tree 来维护。账户状态（Account State）包含四个属性。

nonce: 如果账户是一个外部拥有账户，nonce 代表从此账户地址发送的交易序号。如果账户是一个合约账户，nonce 代表此账户创建的合约序号。用 $\boldsymbol{\sigma}[a]_{\mathbf{n}}$ 来表示。
balance：此地址拥有 Wei 的数量。1Ether=10^18Wei。用 $\boldsymbol{\sigma}[a]_{\mathbf{b}}$ 来表示。
storageRoot：理论上是指 Merkle Patricia 树的根节点 256 位的 Hash 值。用 $\boldsymbol{\sigma}[a]_{\mathbf{s}}$ 来表示。公式 6 中有介绍。
codeHash：此账户 EVM 代码的 hash 值。对于外部拥有账户，codeHash 域是一个空字符串的 Hash 值。对于合约账户，就是代码的 Hash 作为 codeHash 保存。用 $\boldsymbol{\sigma}[a]_{\mathbf{c}}$ 来表示。

// github.com/ethereum/go-ethereum/core/state/state_object.go
type Account struct {
    Nonce    uint64
    Balance  *big.Int
    Root     common.Hash // merkle root of the storage trie
    CodeHash []byte
}

关于 storageRoot 的补充 $\begin{equation} {\small TRIE}\big(L_{I}^*(\boldsymbol{\sigma}[a]_{\mathbf{s}})\big) \equiv \boldsymbol{\sigma}[a]_{\mathrm{s}} \tag{6} \end{equation}$

L I ((k, v)) \equiv (K E C (k), R L P (v)) (7)

$\begin{equation} L_{I}\big((k, v) \big) \equiv \big({\small KEC}(k), {\small RLP}(v)\big) \tag{7} \end{equation}$

k \in B 32 \land v \in N (8)

$\begin{equation} k \in \mathbb{B}_{32} \quad \wedge \quad v \in \mathbb{N} \tag{8} \end{equation}$

公式 6, 由于有些时候我们不仅需要 state 的 hash 值的 trie，而是需要其对应的 kv 数据也包含其中。所以以太坊中的存储 State 的树，不仅包含 State 的 hash，同时也包含了存储这个账户的 address 的 hash 和它对应的 data 也就是其 Account 的值的数据对的集合。这里 storageRoot 实际上是这样的树的根节点 hash 值。

公式 7，指 state 对应的 kv 数据的 RLP 的形式化表示，是 k 的 hash 值作为 key，value 是 v 的 RLP 表示。也就是以太坊中实际存储的 state 是账户 address 的 hash $({\small KEC}(k)）$ , 与其数据 Account 内容的 RLP $({\small RLP}(v))$ 。

公式 8，指公式 7 中的 k 是 32 的字符数组。这个是由 KECCAK256 算法保证的。

注：原本公式 8 中要求的是 v 是个正整数，但是我看来下代码和下文公式 10，感觉这里的 v 都应该是 Account 的内容

一些符号化定义

以太坊中的账户有两类，一类是外部账户，一类是合约账户。其中外部账户被私钥控制且没有任何代码与之关联。合约账户，被它们的合约代码控制且有代码与之关联。以下几个公式定义了账户的各种状态。 $\begin{equation} L_{S}(\boldsymbol{\sigma}) \equiv \{p(a): \boldsymbol{\sigma}[a] \neq \varnothing \} \tag{9} \end{equation}$ 其中 $\begin{equation} p(a) \equiv \big({\small KEC}(a), {\small RLP}\big((\boldsymbol{\sigma}[a]_{\mathrm{n}}, \boldsymbol{\sigma}[a]_{\mathrm{b}}, \boldsymbol{\sigma}[a]_{\mathrm{s}}, \boldsymbol{\sigma}[a]_{\mathrm{c}}) \big) \big) \tag{10} \end{equation}$

\forall a : σ [a] = \emptyset \lor (a \in B 20 \land v (σ [a])) (11)

$\begin{equation} \forall a: \boldsymbol{\sigma}[a] = \varnothing \vee (a \in \mathbb{B}_{20} \wedge v(\boldsymbol{\sigma}[a])) \tag{11} \end{equation}$

v (x) \equiv x n \in N 256 \land x b \in N 256 \land x s \in B 32 \land x c \in B 32 (12)

$\begin{equation} v(x) \equiv {x}_{\mathrm{n}} \in \mathbb{N}_{256} \wedge {x}_{\mathrm{b}} \in \mathbb{N}_{256} \wedge {x}_{\mathrm{s}} \in \mathbb{B}_{32} \wedge {x}_{\mathrm{c}} \in \mathbb{B}_{32} \tag{12} \end{equation}$

E M P T Y (σ, a) \equiv σ [a] c = K E C (()) \land σ [a] n = 0 \land σ [a] b = 0 (13)

$\begin{equation} \mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \quad \equiv \quad \boldsymbol{\sigma}[a]_{\mathrm{c}} = {\small KEC} \big(()\big) \wedge \boldsymbol{\sigma}[a]_{\mathrm{n}} = 0 \wedge \boldsymbol{\sigma}[a]_{\mathrm{b}} = 0 \tag{13} \end{equation}$

D E A D (σ, a) \equiv σ [a] = \emptyset \lor E M P T Y (σ, a) (14)

$\begin{equation} \mathtt{\tiny DEAD}(\boldsymbol{\sigma}, a) \quad\equiv\quad \boldsymbol{\sigma}[a] = \varnothing \vee \mathtt{\tiny EMPTY}(\boldsymbol{\sigma}, a) \tag{14} \end{equation}$

公式 9，定义了函数 $L_{S}$ ，意思是若账户 $a$ 不为空，则返回账户 $p(a)$ 。

公式 10，定义 $p(a)$ , $p(a)$ 其实就是我们上面公式 7，解释 $k$ ， $v$ 对的时候的 kv 对。包括 address 的 hash 值，以及 Account 内容的 RLP 结果。

公式 11 与公式 12，对账户 $a$ 做了定义，表示账户要么为空，要么就是一个 a 为 20 个长度的字符，其 nonce 值为小于 2 ²⁵⁶的正整数，balance 值为小于 2 ²⁵⁶的正整数，storageRoot 为 32 位的字符，codeHash 为 32 的字符。

公式 13，定义了空账户。若一个账户，其地址为空字符，并且该账户 nonce 值为 0，balance 值也为 0.

公式 14，定义了死账户，死账户要么为空 $\varnothing$ ，要么是一个 EMPTY 账户。

2.2 交易

nonce: 与发送该交易的账户的 nonce 值一致。用 $T_{\mathrm{n}}$ 表示。
gasPrice: 表示每 gas 的单价为多少 wei。用 $T_{\mathrm{p}}$ 表示。
gasLimit: 执行该条交易最大被允许使用的 gas 数目。用 $T_{\mathrm{g}}$ 表示。
to:160 位的接受者地址。当交易位创建合约时，该值位空。用 $T_{\mathrm{t}}$ 表示。
value: 表示发送者发送的 wei 的数目。该值为向接受者转移的 wei 的数目，或者是创建合约时作为合约账户的初始 wei 数目。用 $T_{\mathrm{v}}$ 表示。
v,r,s: 交易的签名信息，用以决定交易的发送者。分别用 $T_{\mathrm{w}}$ , $T_{\mathrm{r}}$ , $T_{\mathrm{s}}$ 表示。
init: 如果是创建合约的交易, 则 init 表示一段不限长度的 EVM-Code 用以合约账户初始化的过程。用 $T_{\mathrm{i}}$ 表示。
data: 调用合约的交易，会包含一段不限长度的输入信息，用 $T_{\mathrm{d}}$ 表示。

// github.com/ethereum/go-ethereum/core/types/transaction.go
type Transaction struct {
    data txdata
    // caches
    hash atomic.Value
    size atomic.Value
    from atomic.Value
}
type txdata struct {
    AccountNonce uint64          `json:"nonce"    gencodec:"required"`
    Price        *big.Int        `json:"gasPrice" gencodec:"required"`
    GasLimit     uint64          `json:"gas"      gencodec:"required"`
    Recipient    *common.Address `json:"to"       rlp:"nil"` // nil means contract creation
    Amount       *big.Int        `json:"value"    gencodec:"required"`
    Payload      []byte          `json:"input"    gencodec:"required"`

    // Signature values
    V *big.Int `json:"v" gencodec:"required"`
    R *big.Int `json:"r" gencodec:"required"`
    S *big.Int `json:"s" gencodec:"required"`

    // This is only used when marshaling to JSON.
    Hash *common.Hash `json:"hash" rlp:"-"`
}

一些符号化定义 $\begin{equation} L_{T}(T) \equiv \begin{cases} (T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, T_{\mathbf{i}}, T_{\mathrm{w}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{if} \; T_{\mathrm{t}} = \varnothing\\ (T_{\mathrm{n}}, T_{\mathrm{p}}, T_{\mathrm{g}}, T_{\mathrm{t}}, T_{\mathrm{v}}, T_{\mathbf{d}}, T_{\mathrm{w}}, T_{\mathrm{r}}, T_{\mathrm{s}}) & \text{otherwise} \end{cases} \tag{15} \end{equation}$

T n \in N 256 T g \in N 256 T s \in N 256 \land \land \land T v \in N 256 T w \in N 5 T d \in B \land \land \land T p \in N 256 T r \in N 256 T i \in B \land \land (16)

$\begin{equation} \begin{array} \quad T_{\mathrm{n}} \in \mathbb{N}_{256} & \wedge & T_{\mathrm{v}} \in \mathbb{N}_{256} & \wedge & T_{\mathrm{p}} \in \mathbb{N}_{256} & \wedge \\ T_{\mathrm{g}} \in \mathbb{N}_{256} & \wedge & T_{\mathrm{w}} \in \mathbb{N}_5 & \wedge & T_{\mathrm{r}} \in \mathbb{N}_{256} & \wedge \\ T_{\mathrm{s}} \in \mathbb{N}_{256} & \wedge & T_{\mathbf{d}} \in \mathbb{B} & \wedge & T_{\mathbf{i}} \in \mathbb{B} \end{array} \tag{16} \end{equation}$

N n = {P : P \in N \land P < 2 n} (17)

$\begin{equation} \mathbb{N}_{\mathrm{n}} = \{P: P \in \mathbb{N} \wedge P <2^n \} \tag{17} \end{equation}$

$\begin{equation} T_{\mathbf{t}} \in \begin{cases} \mathbb{B}_{20} & \text{if} \quad T_{\mathrm{t}} \neq \varnothing \\ \mathbb{B}_{0} & \text{otherwise}\end{cases} \tag{18} \end{equation}$

以太坊中根据交易中的 to 值是否为空，可以判断交易是创建合约还是执行合约。

公式 15 表示，如果 to 的值 $T_{\mathrm{t}}$ 为空，则交易是创建合约的交易，需要有 init 数据。交易的 RLP 形式化可以表示为 nonce $T_{\mathrm{n}}$ ，gasPrice $T_{\mathrm{p}}$ , gasLimit $T_{\mathrm{g}}$ , to $T_{\mathrm{t}}$ ，value $T_{\mathrm{v}}$ ，init $T_{\mathrm{i}}$ ，“v ，r， s” $T_{\mathrm{w}}$ , $T_{\mathrm{r}}$ , $T_{\mathrm{s}}$ 。如果 $T_{\mathrm{t}}$ 不为空，则交易是执行合约的交易，需要有 data 数据。交易的 RLP 形式化可以表示为 nonce $T_{\mathrm{n}}$ ，gasPrice $T_{\mathrm{p}}$ , gasLimit $T_{\mathrm{g}}$ , to $T_{\mathrm{t}}$ ，value $T_{\mathrm{v}}$ ，data $T_{\mathrm{d}}$ ，“v ，r， s” $T_{\mathrm{w}}$ , $T_{\mathrm{r}}$ , $T_{\mathrm{s}}$ 。

公式 16，是对交易的各个字段限制的符号化定义。其意思是 nonce、value、gasPrice、gasLimit 以及特殊的用来验证签名的 r 和 s 都是小于 2 ²⁵⁶的正整数，用来验证签名的 v ( $T_{\mathrm{w}}$ )是小于 2 ⁵的正整数。而 init 和 data 都是未知长度的字符数组。

公式 17，是对 $\mathbb{N}_{\mathrm{n}}$ 的定义，即小于 2 ⁿ的正整数。

公式 18，是对交易中的 to 字段的符号化定义，当其不为空的时候，是 20 位的字符，为空的时候是 0 位字符。

2.3 区块

以太坊中的一个区块由区块头 Header，以及交易列表 $B_{\mathbf{T}}$ , 以及 ommerblock 的 header 集合 $B_{\mathbf{U}}$ 三部分组成。

Header 包括以下字段。

parentHash: 父节点的 hash 值。用 $H_{\mathrm{p}}$ 表示。
ommersHash: uncle 节点的 hash 值，这块是跟 GHOST 相关的，用 $H_{\mathrm{o}}$ 表示。
beneficiary: 矿工 address，用 $H_{\mathrm{c}}$ 表示。
stateRoot: 当所有交易都执行完毕后的世界状态树的根节点，用 $H_{\mathrm{r}}$ 表示。
transactionsRoot: 交易列表的根节点，用 $H_{\mathrm{t}}$ 表示。
receiptsRoot: 收据的根节点，用 $H_{\mathrm{e}}$ 表示。
logsBloom: 日志过滤器，用 $H_{\mathrm{b}}$ 表示。这个暂时没细看，不太确定。
difficulty: 区块难度，根据上一个区块的难度以及时间戳算出来的值，用 $H_{\mathrm{d}}$ 表示。
number: 区块号，用 $H_{\mathrm{i}}$ 表示。
gasLimit: 区块的 gas 数量限制，即区块中交易使用掉的 gas 值不应该超过该值。用 $H_{\mathrm{l}}$ 表示。
gasUsed: 区块使用掉的 gas 数量，用 $H_{\mathrm{g}}$ 表示。
timestamp: 时间戳，用 $H_{\mathrm{s}}$ 表示。
extraData: 额外的数据，合法的交易对长度有限制，用 $H_{\mathrm{x}}$ 表示。
mixHash: 与 nonce 一起用作工作量证明，用 $H_{\mathrm{m}}$ 表示。
nonce: 与 mixHash 一起用作工作量证明，用 $H_{\mathrm{n}}$ 表示。

// github.com/ethereum/go-ethereum/core/types/block.go
// "external" block encoding. used for eth protocol, etc.
type extblock struct {
    Header *Header
    Txs    []*Transaction
    Uncles []*Header
}

// Header represents a block header in the Ethereum blockchain.
type Header struct {
    ParentHash  common.Hash    `json:"parentHash"       gencodec:"required"`
    UncleHash   common.Hash    `json:"sha3Uncles"       gencodec:"required"`
    Coinbase    common.Address `json:"miner"            gencodec:"required"`
    Root        common.Hash    `json:"stateRoot"        gencodec:"required"`
    TxHash      common.Hash    `json:"transactionsRoot" gencodec:"required"`
    ReceiptHash common.Hash    `json:"receiptsRoot"     gencodec:"required"`
    Bloom       Bloom          `json:"logsBloom"        gencodec:"required"`
    Difficulty  *big.Int       `json:"difficulty"       gencodec:"required"`
    Number      *big.Int       `json:"number"           gencodec:"required"`
    GasLimit    uint64         `json:"gasLimit"         gencodec:"required"`
    GasUsed     uint64         `json:"gasUsed"          gencodec:"required"`
    Time        *big.Int       `json:"timestamp"        gencodec:"required"`
    Extra       []byte         `json:"extraData"        gencodec:"required"`
    MixDigest   common.Hash    `json:"mixHash"          gencodec:"required"`
    Nonce       BlockNonce     `json:"nonce"            gencodec:"required"`
}
// Receipt represents the results of a transaction.
type Receipt struct {
    // Consensus fields
    PostState         []byte `json:"root"`
    Status            uint   `json:"status"`
    CumulativeGasUsed uint64 `json:"cumulativeGasUsed" gencodec:"required"`
    Bloom             Bloom  `json:"logsBloom"         gencodec:"required"`
    Logs              []*Log `json:"logs"              gencodec:"required"`

    // Implementation fields (don't reorder!)
    TxHash          common.Hash    `json:"transactionHash" gencodec:"required"`
    ContractAddress common.Address `json:"contractAddress"`
    GasUsed         uint64         `json:"gasUsed" gencodec:"required"`
}

区块的符号化定义 $\begin{equation} B \equiv (B_{H}, B_{\mathbf{T}}, B_{\mathbf{U}}) \tag{19} \end{equation}$ 公式 19，表示区块由三部分组成，区块头 $B_{H}$ ，交易列表 $B_{\mathbf{T}}$ , 以及 ommerblock 的 header 集合 $B_{\mathbf{U}}$ 。

2.3.1 交易收据

以太坊中为了将交易的信息进行编码，以方便索引以及查找或者零知识证明等相关的东西，为每条交易定义了一定收据。对于第 i 个交易，其收据用 $B_R$ [i] 表示。

每条收据都是一个四元组，包括区块当前累计使用的 gas 值 $R_{\mathrm{u}}$ ，交易执行产生的 log $R_{\mathrm{l}}$ ，日志过滤器 $R_{\mathrm{b}}$ ，以及状态码 $R_{\mathrm{z}}$ 。
$\begin{equation}<br>R \equiv (R_{\mathrm{u}}, R_{\mathrm{b}}, R_{\mathbf{l}}, R_{\mathrm{z}})<br>\tag{20}<br>\end{equation}$

L R (R) \equiv (0 \in B 256, R u, R b, R l) (21)

$\begin{equation} L_{R}(R) \equiv (0 \in \mathbb{B}_{256}, R_{\mathrm{u}}, R_{\mathrm{b}}, R_{\mathbf{l}}) \tag{21} \end{equation}$

R z \in N (22)

$\begin{equation} R_{\mathrm{z}} \in \mathbb{N} \tag{22} \end{equation}$

R u \in N \land R b \in B 256 (23)

$\begin{equation} R_{\mathrm{u}} \in \mathbb{N} \quad \wedge \quad R_{\mathrm{b}} \in \mathbb{B}_{256} \tag{23} \end{equation}$

O \equiv (O a, (O t 0, O t 1, . . .), O d) (24)

$\begin{equation} O \equiv (O_{\mathrm{a}}, ({O_{\mathbf{t}}}_0, {O_{\mathbf{t}}}_1, ...), O_{\mathbf{d}}) \tag{24} \end{equation}$

$\begin{equation} O_{\mathrm{a}} \in \mathbb{B}_{20} \wedge \forall_{t \in O_{\mathbf{t}}}: t \in \mathbb{B}_{32} \wedge O_{\mathbf{d}} \in \mathbb{B} \tag{25} \end{equation}$

公式 20 对区块头中的收据作了定义，收据是个四元组，四元组定义如前文。

公式 21，收据的 RLP 形式化表示为 $L_{R}(R)$ 。其中 $0 \in \mathbb{B}_{256}$ 在之前版本的协议中是交易执行之前的 stateRoot。现在被替换为 0.

公式 22，表示 $R_{\mathrm{z}}$ 状态码是正整数。

公式 23 对收据中当前累计使用的 gas 值 $R_{\mathrm{u}}$ ，和日志过滤器 $R_{\mathrm{b}}$ 进行了描述。显然累计 gas 值 $R_{\mathrm{u}}$ 是一个正整数。而日志过滤器 $R_{\mathrm{b}}$ 是 256 位字符。

公式 24 对交易执行的日志 $R_{\mathrm{l}}$ 进行了解释。

公式 25 对其限制进行了描述。 $R_{\mathrm{l}}$ 是日志条目的序列。日志条目需要包括纪录日志者的地址，以及日志话题分类，以及实际数据。日志条目用 O 来表示，用 $O_{\mathrm{a}}$ 表示日志纪录者的 address，用 $O_{\mathrm{t}}$ 来表示一些列 32 位字符的日志主题 (log topics), 用 $O_{\mathrm{d}}$ 来表示字符数据。其中日志纪录者的 address $O_{\mathrm{a}}$ 是 20 位字符，每一个日志分类话题 $O_{\mathrm{t}}$ 是一个 32 位字符，而日志数据 $O_{\mathrm{d}}$ 是未知长度的字符。

公式 26-30. 对日志过滤函数做了定义，这块涉及到东西是数据操作层面的，不影响对流程的理解。暂不作解释。

2.3.2 整体的合法性

上面介绍过了区块包含区块头，区块交易列表，以及区块的 ommer 区块的头三部分。以太坊中判断一个区块是否合法，首先需要对区块整体上做合法性判断。见公式 31

其区块头的状态树的根 stateRoot 也就是 $H_{\mathrm{r}}$ ，是否确实是状态树的根。
其区块头的 ommerHash 也就是 $H_{\mathrm{o}}$ , 是否与区块的 ommer 区块的头部分的 hash 值一致。
其区块头中的 transactionRoot 也就是 $H_{\mathrm{t}},f$ 即区块中交易的树的根，是否和区块存储的交易列表中的交易一一对应。一一对应关系见公式 32，是将交易所在列表中的索引的 RLP 作为键，交易内容 v 的 RLP 作为值的键值对。
其区块头中的 recieptRoot 也就是 $H_{\mathrm{e}}$ ，即区块中收据的树的根，是否和区块存储的交易列表一一对应，是不是每条交易都有一条相应的收据。一一对应关系见公式 32，是将收据所在列表中的索引的 RLP 作为键，收据内容 v 的 RLP 作为值的键值对。
区块头中 logsBloom 也就是 $H_{\mathrm{b}}$ ，是否包含了区块的交易的所有日志。
执行该区块之前的状态树的根节点，是否与其父区块的中的根节点一致。见公式 33.

H r H o H t H e H b \equiv \equiv \equiv \equiv \equiv T R I E (L S (Π (σ, B))) K E C (R L P (L * H (B U))) T R I E ({\forall i < ∥ B T ∥, i \in P : p (i, L T (B T [i]))}) T R I E ({\forall i < ∥ B R ∥, i \in P : p (i, L R (B R [i]))}) ⋁ r \in B R (r b) \land \land \land \land (31)

$\begin{equation} \begin{array} {}H_{\mathrm{r}} &\equiv& \mathtt{\small TRIE}(L_S(\Pi(\boldsymbol{\sigma}, B))) & \wedge \\ {}H_{\mathrm{o}} &\equiv& \mathtt{\small KEC}(\mathtt{\small RLP}(L_H^*(B_{\mathbf{U}}))) & \wedge \\ {}H_{\mathrm{t}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_{\mathbf{T}} \rVert, i \in \mathbb{P}: \quad p (i, L_{T}(B_{\mathbf{T}}[i]))\}) & \wedge \\ {}H_{\mathrm{e}} &\equiv& \mathtt{\small TRIE}(\{\forall i < \lVert B_{\mathbf{R}} \rVert, i \in \mathbb{P}: \quad p(i, {L_{R}}(B_{\mathbf{R}}[i]))\}) & \wedge \\ {}H_{\mathrm{b}} &\equiv& \bigvee_{\mathbf{r} \in B_{\mathbf{R}}} \big(\mathbf{r}_{\mathrm{b}} \big) \end{array} \tag{31} \end{equation}$

p (k, v) \equiv (R L P (k), R L P (v)) (32)

$\begin{equation} p(k, v) \equiv \big(\mathtt{\small RLP}(k), \mathtt{\small RLP}(v) \big) \tag{32} \end{equation}$

$\begin{equation} \mathtt{\small TRIE}(L_{S}(\boldsymbol{\sigma})) = {P(B_H)_H}_{\mathrm{r}} \tag{33} \end{equation}$

2.3.3 序列化

对区块，以及区块头的序列化表示如下。

L H (H) \equiv (H p, H o, H c, H r, H t, H e, H b, H d, H i, H l, H g, H s, H x, H m, H n) (34)

$\begin{equation} \quad L_{H}(H) \equiv ({}H_{\mathrm{p}}, H_{\mathrm{o}}, H_{\mathrm{c}}, H_{\mathrm{r}}, H_{\mathrm{t}}, H_{\mathrm{e}}, H_{\mathrm{b}}, H_{\mathrm{d}}, H_{\mathrm{i}}, H_{\mathrm{l}}, H_{\mathrm{g}}, H_{\mathrm{s}}, H_{\mathrm{x}}, H_{\mathrm{m}}, H_{\mathrm{n}} ) \tag{34} \end{equation}$

L B (B) \equiv (L H (B H), L * T (B T), L * H (B U)) (35)

$\begin{equation} \quad L_{B}(B) \equiv \big(L_{H}(B_{H}), L_{T}^*(B_{\mathbf{T}}), L_{H}^*({B_{\mathbf{U}}}) \big) \tag{35} \end{equation}$

f * ((x 0, x 1, . . .)) \equiv (f (x 0), f (x 1), . . .) (36)

$\begin{equation} {f^*}\big((x_0, x_1, ...) \big) \equiv \big(f(x_0), f(x_1), ... \big) \quad \tag{36} \end{equation}$

H p \in B 32 H r \in B 32 H b \in B 256 H l \in N H x \in B \land \land \land \land \land H o \in B 32 H t \in B 32 H d \in N H g \in N H m \in B 32 \land \land \land \land \land H c \in B 20 H e \in B 32 H i \in N H s \in N 256 H n \in B 8 \land \land \land \land (37)

$\begin{equation} \begin{array}[t]{lclclcl} {H_{\mathrm{p}}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{o}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{c}} \in \mathbb{B}_{20} & \wedge \\ {H_{\mathrm{r}}} \in \mathbb{B}_{32} & \wedge & H_{\mathrm{t}} \in \mathbb{B}_{32} & \wedge & {H_{\mathrm{e}}} \in \mathbb{B}_{32} & \wedge \\ {H_{\mathrm{b}}} \in \mathbb{B}_{256} & \wedge & H_{\mathrm{d}} \in \mathbb{N} & \wedge & {H_{\mathrm{i}}} \in \mathbb{N} & \wedge \\ {H_{\mathrm{l}}} \in \mathbb{N} & \wedge & H_{\mathrm{g}} \in \mathbb{N} & \wedge & {H_{\mathrm{s}}} \in \mathbb{N}_{256} & \wedge \\ {H_{\mathrm{x}}} \in \mathbb{B} & \wedge & H_{\mathrm{m}} \in \mathbb{B}_{32} & \wedge & {H_{\mathrm{n}}} \in \mathbb{B}_{8} \end{array} \tag{37} \end{equation}$

公式 34 是区块头的序列化表示。

公式 35 是区块的序列化表示，即分别将区块头序列化，区块的交易列表，ommer 区块头序列化。其中交易序列化函数 $L_T$ 见公式 15.

公式 36 表示列表序列化和当个序列化的关系，列表的序列化，就是把列表中的元素分别序列化，然后将结果组成列表。

公式 37 是对区块头中属性的限制规定：

各种 hash 值都是 32 位字符。包括 parentHash $H_{\mathrm{p}}$ ,ommerHash $H_{\mathrm{o}}$ , stateRoot $H_{\mathrm{r}}$ , transactionRoot $H_{\mathrm{t}}$ , RecieptRoot $H_{\mathrm{e}}$ , mixHash $H_{\mathrm{m}}$ 。
受益人也就是挖矿的人的地址 beneficiary $H_{\mathrm{c}}$ , 是 20 位字符。
日志过滤器 logBoom $H_{\mathrm{b}}$ , 是 256 位字符。
难度，区块号，gas 限制，用掉的 gas 等都是正整数。difficulty $H_{\mathrm{d}}$ , Number $H_{\mathrm{i}}$ ,gasLimit $H_{\mathrm{l}}$ gasUsed $H_{\mathrm{g}}$
时间戳 timestamp $H_{\mathrm{s}}$ 是个大的正整数，其值小于 2 ²⁵⁶。
额外的数据 extraData $H_{\mathrm{x}}$ 是未知长度字符。
nonce $H_{\mathrm{n}}$ 是 8 位的字符。
2.3.4 区块头的合法性

确定区块是否合法除了整体性的合法校验，还需要对区块头进行更进一步的校验。主要校验规则有以下几点：
parentHash 正确。即 parentHash 与其父区块的头的 hash 一致。
number 为父区块 number 值加一。
difficuilty 难度正确。区块合理的难度跟父区块难度，以及当前区块时间戳和父区块时间戳间隔以及区块编号有关。难度可以起到一定的调节出块时间的作用。，可以看出当出块变快（也就是出块间隔变小之后）难度会增加，相反难度会减小。
gasLimit 和上一个区块的差值在规定范围内。
gasUsed 小于等于 gasLimit
timestamp 时间戳必须大于上一区块的时间戳。
mixHash 和 nonce 必须满足 PoW。
extraData 最多为 32 个字节。

// verifyHeader checks whether a header conforms to the consensus rules of the
// stock Ethereum ethash engine.
// See YP section 4.3.4. "Block Header Validity"
func (ethash *Ethash) verifyHeader(chain consensus.ChainReader, header, parent *types.Header, uncle bool, seal bool) error {
    // Ensure that the header's extra-data section is of a reasonable size
      // 验证extraData的长度
    if uint64(len(header.Extra)) > params.MaximumExtraDataSize {
        return fmt.Errorf("extra-data too long: %d > %d", len(header.Extra), params.MaximumExtraDataSize)
    }
    // Verify the header's timestamp
    // 验证时间戳是否超过大小限制，是否过大，是否大于上一区块的时间戳等
    if uncle {
        if header.Time.Cmp(math.MaxBig256) > 0 {
            return errLargeBlockTime
        }
    } else {
        if header.Time.Cmp(big.NewInt(time.Now().Add(allowedFutureBlockTime).Unix())) > 0 {
            return consensus.ErrFutureBlock
        }
    }
    if header.Time.Cmp(parent.Time) <= 0 {
        return errZeroBlockTime
    }

      // 验证难度是否正确
    // Verify the block's difficulty based in it's timestamp and parent's difficulty
    expected := ethash.CalcDifficulty(chain, header.Time.Uint64(), parent)

    if expected.Cmp(header.Difficulty) != 0 {
        return fmt.Errorf("invalid difficulty: have %v, want %v", header.Difficulty, expected)
    }
    // Verify that the gas limit is <= 2^63-1
    cap := uint64(0x7fffffffffffffff)
     //验证gasLimit是否超了上限
    if header.GasLimit > cap {
        return fmt.Errorf("invalid gasLimit: have %v, max %v", header.GasLimit, cap)
    }
     //验证已用的gas值是否小于等于gasLimit
    // Verify that the gasUsed is <= gasLimit
    if header.GasUsed > header.GasLimit {
        return fmt.Errorf("invalid gasUsed: have %d, gasLimit %d", header.GasUsed, header.GasLimit)
    }

    // Verify that the gas limit remains within allowed bounds
    //判断gasLimit与父区块的gasLimit差值是否在规定范围内
    diff := int64(parent.GasLimit) - int64(header.GasLimit)
    if diff < 0 {
        diff *= -1
    }
    limit := parent.GasLimit / params.GasLimitBoundDivisor

    if uint64(diff) >= limit || header.GasLimit < params.MinGasLimit {
        return fmt.Errorf("invalid gas limit: have %d, want %d += %d", header.GasLimit, parent.GasLimit, limit)
    }
    // Verify that the block number is parent's +1
        //验证区块号，是否是父区块号+1
    if diff := new(big.Int).Sub(header.Number, parent.Number); diff.Cmp(big.NewInt(1)) != 0 {
        return consensus.ErrInvalidNumber
    }
    // Verify the engine specific seal securing the block
     //验证PoW
    if seal {
        if err := ethash.VerifySeal(chain, header); err != nil {
            return err
        }
    }
    // If all checks passed, validate any special fields for hard forks
    if err := misc.VerifyDAOHeaderExtraData(chain.Config(), header); err != nil {
        return err
    }
    if err := misc.VerifyForkHashes(chain.Config(), header, uncle); err != nil {
        return err
    }
    return nil
}

校验区块号和区块 hash 的符号化表示 $\begin{equation} P(H) \equiv B': \mathtt{\tiny KEC}(\mathtt{\tiny RLP}(B'_{H})) = {H_{\mathrm{p}}} \tag{39} \end{equation}$

H i \equiv P (H) H i + 1 (40)

$\begin{equation} H_{\mathrm{i}} \equiv P(H)_{H_{\mathrm{i}}} + 1 \tag{40} \end{equation}$

公式 39 表示，parentHash 值应该为父节点 Header 的 hash 值。

公式 40 表示，number 为父节点 number + 1.

难度计算的符号化表示 $\begin{equation} D(H) \equiv \begin{cases} D_0 & \text{if} \quad H_{\mathrm{i}} = 0\\ \text{max}\!\left(D_0, {P(H)_{H}}_{\mathrm{d}} + {x}\times{\varsigma_2} + {\epsilon} \right) & \text{otherwise}\\ \end{cases} \tag{41} \end{equation}$

D 0 \equiv 131072 (42)

$\begin{equation} D_0 \equiv 131072 \tag{42} \end{equation}$

x \equiv ⌊ P ( H ) H d 2048 ⌋ (43)

$\begin{equation} {x} \equiv \left\lfloor\frac{P(H)_{H_{\mathrm{d}}}}{2048}\right\rfloor \tag{43} \end{equation}$

ς 2 \equiv max (y - ⌊ H s - P ( H ) H s 9 ⌋, - 99) (44)

$\begin{equation} {\varsigma_2} \equiv \text{max}\left(y - \left\lfloor\frac{H_{\mathrm{s}} - {P(H)_{H}}_{\mathrm{s}}}{9}\right\rfloor, -99 \right) \tag{44} \end{equation}$

y \equiv {12 if ∥ P (H) U ∥ = 0 otherwise

$\begin{equation*} y \equiv \begin{cases} 1 & \text{if} \, \lVert P(H)_{\mathbf{U}}\rVert = 0 \\ 2 & \text{otherwise} \end{cases} \end{equation*}$

ϵ \equiv ⌊ 2 ⌊ H' i \div 100000 ⌋ - 2 ⌋ (45)

$\begin{equation} \epsilon \equiv \left\lfloor 2^{\left\lfloor H'_{\mathrm{i}} \div 100000 \right\rfloor - 2 } \right\rfloor \tag{45} \end{equation}$

H' i \equiv max (H i - 3000000, 0) (46)

$\begin{equation} H'_{\mathrm{i}} \equiv \max(H_{\mathrm{i}} - 3000000, 0) \tag{46} \end{equation}$

公式 41-46 为 difficulty 的计算方法。

公式 41，42 表示，当区块编号为 0 的时候其难度值是固定好的，在这里用 $D_0$ 表示，其值为 131072. 对于其他区块，其难度值需要根据其父区块难度值以及一些其他因素，出块的间隔时间，区块编号等有关进行调节的，若小于 $D_0$ ，则难度值调整为 $D_0$ 。

公式 43，调节系数（the adjustment factor ） $x$ 的定义。

公式 44，难度系数（diculty parameter） ${\varsigma_2}$ 的定义。该系数主要与出块间隔时间有关，当间隔大的时候，系数变大，难度也会相应变大，当间隔小的时候，系数变小，难度也会变小。使得区块链在整体上出块时间是趋于稳定的。其中 $y$ 值根据父节点的 uncle 节点是否为空而有所区别，可以看出当父节点的 uncle 不为空的时候， $y$ 值为 2，说明当前的分叉程度较大，适当调大难度，一定程度上会减少分叉。

公式 45，46，“difficulty bomb”, or “ice age” ${\epsilon}$ 的定义。（看说明好像是为了将来切 PoS 共识的时候，调节难度用）

// CalcDifficulty is the difficulty adjustment algorithm. It returns
// the difficulty that a new block should have when created at time
// given the parent block's time and difficulty.
func (ethash *Ethash) CalcDifficulty(chain consensus.ChainReader, time uint64, parent *types.Header) *big.Int {
    return CalcDifficulty(chain.Config(), time, parent)
}

// CalcDifficulty is the difficulty adjustment algorithm. It returns
// the difficulty that a new block should have when created at time
// given the parent block's time and difficulty.
func CalcDifficulty(config *params.ChainConfig, time uint64, parent *types.Header) *big.Int {
    next := new(big.Int).Add(parent.Number, big1)
    switch {
    case config.IsByzantium(next):
        return calcDifficultyByzantium(time, parent)
    case config.IsHomestead(next):
        return calcDifficultyHomestead(time, parent)
    default:
        return calcDifficultyFrontier(time, parent)
    }
}

// 黄皮书中的介绍的是Byzantium难度协议，所以这里只给出相应的代码。其他几种难度调节协议只是参数值上有区别。
// calcDifficultyByzantium is the difficulty adjustment algorithm. It returns
// the difficulty that a new block should have when created at time given the
// parent block's time and difficulty. The calculation uses the Byzantium rules.
func calcDifficultyByzantium(time uint64, parent *types.Header) *big.Int {
    // https://github.com/ethereum/EIPs/issues/100.
    // algorithm:
    // diff = (parent_diff +
    //         (parent_diff / 2048 * max((2 if len(parent.uncles) else 1) - ((timestamp - parent.timestamp) // 9), -99))
    //        ) + 2^(periodCount - 2)

    bigTime := new(big.Int).SetUint64(time)
    bigParentTime := new(big.Int).Set(parent.Time)

    // holds intermediate values to make the algo easier to read & audit
    x := new(big.Int)
    y := new(big.Int)

    // (2 if len(parent_uncles) else 1) - (block_timestamp - parent_timestamp) // 9
    x.Sub(bigTime, bigParentTime)
    x.Div(x, big9)
    if parent.UncleHash == types.EmptyUncleHash {
        x.Sub(big1, x)
    } else {
        x.Sub(big2, x)
    }
    // max((2 if len(parent_uncles) else 1) - (block_timestamp - parent_timestamp) // 9, -99)
    if x.Cmp(bigMinus99) < 0 {
        x.Set(bigMinus99)
    }
    // parent_diff + (parent_diff / 2048 * max((2 if len(parent.uncles) else 1) - ((timestamp - parent.timestamp) // 9), -99))
    y.Div(parent.Difficulty, params.DifficultyBoundDivisor)
    x.Mul(y, x)
    x.Add(parent.Difficulty, x)

    // minimum difficulty can ever be (before exponential factor)
    if x.Cmp(params.MinimumDifficulty) < 0 {
        x.Set(params.MinimumDifficulty)
    }
    // calculate a fake block number for the ice-age delay:
    //   https://github.com/ethereum/EIPs/pull/669
    //   fake_block_number = min(0, block.number - 3_000_000
    fakeBlockNumber := new(big.Int)
    if parent.Number.Cmp(big2999999) >= 0 {
        fakeBlockNumber = fakeBlockNumber.Sub(parent.Number, big2999999) // Note, parent is 1 less than the actual block number
    }
    // for the exponential factor
    periodCount := fakeBlockNumber
    periodCount.Div(periodCount, expDiffPeriod)

    // the exponential factor, commonly referred to as "the bomb"
    // diff = diff + 2^(periodCount - 2)
    if periodCount.Cmp(big1) > 0 {
        y.Sub(periodCount, big2)
        y.Exp(big2, y, nil)
        x.Add(x, y)
    }
    return x
}

gasLimit 限制的符号化表示 $\begin{eqnarray} \nonumber & & H_{\mathrm{l}} <{P(H)_{H_{\mathrm{l}}}} + \left\lfloor\frac{P(H)_{H_{\mathrm{l}}}}{1024}\right\rfloor \quad \wedge \\ \nonumber & & H_{\mathrm{l}} > {P(H)_{H_{\mathrm{l}}}} - \left\lfloor\frac{P(H)_{H_{\mathrm{l}}}}{1024}\right\rfloor \quad \wedge \\ \nonumber & & H_{\mathrm{l}} \geqslant 5000 \tag{47} \end{eqnarray}$

公式 47 表示区块的 gasLimit 必须大于等于 5000，且其和上一个区块的 gasLimit 差值不超过 $\left\lfloor\frac{P(H)_{H_l}}{1024}\right\rfloor$

时间戳的符号化表示

H s > P (H) H s (48)

$\begin{equation} H_{\mathrm{s}} > {P(H)_{H}}_{\mathrm{s}} \tag{48} \end{equation}$

公式 48 表示当前区块的时间戳必须大于父区块的时间戳。（代码中要求区块的时间戳不能比当前时间大 15 秒以上）

mixHash 和 nonce 相关符号化表示

n ⩽ 2 256 H d \land m = H m (49)

$\begin{equation} n \leqslant \frac{2^{256}}{H_{\mathrm{d}}} \quad \wedge \quad m = H_{\mathrm{m}} \tag{49} \end{equation}$

参考资料：

黄皮书解析
 以太坊黄皮书中文版

网站*

加入讨论吧...