区块链底层-区块与交易

本文最后更新于：2023年6月19日 晚上

全局结构

下图是以太坊区块数据结构与关系。

区块分为两部分：区块头(Header)和区块体(Body)。区块头信息量非常丰富，不但和上一个单元建立联系还记录了一些交易执行情况信息和矿工工作信息。

定义代码

下面是以太坊代码中定义的区块头和区块体结构定义代码，所有核心代码均在 core/types/block.go 文件中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
//core/types/block.go:70
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        uint64         `json:"timestamp"        gencodec:"required"`
   Extra       []byte         `json:"extraData"        gencodec:"required"`
   MixDigest   common.Hash    `json:"mixHash"`
   Nonce       BlockNonce     `json:"nonce"`
}
type Body struct {
	Transactions []*Transaction
	Uncles       []*Header
}

名词解释

parentHash

是一个哈希值，记录此区块直接引用的父区块哈希值。通过此记录，才能完整的将区块有序组织，形成一条区块链。并且可以防止父区块内容被修改，因为数据修改，区块哈希必然发生变化，因此一个区块直接或间接的强化了所有父辈区块，通过加密算法保证历史区块不可能被修改。

miner

是一个地址，表示区块是此账户的矿工挖出，挖矿奖励将下发到此账户。

transactionsRoot

是一个哈希值，表示该区块中所有交易生成一颗默克尔树根节点哈希值。是一个密码学保证交易集合摘要。通过此 Root 可以直接校验某交易是否包含在此区块中。

mixHash

是一个哈希值。用于校验区块是否正确挖出。实际上是区块头数据不包含 nonce 时的一个哈希值。

区块体

区块体 Body 中只有两项数据：交易集合和叔辈区块头集合。是交易促使以太坊世界态进行转变。

从创世状态开始，每一个区块中的交易执行促使了以太坊世界态的转变。下一个状态是在上一个状态中执行交易或其他操作使得状态由 A 状态转变为 B 状态。
而交易则为状态转变的催化酶，一个区块中的所有交易执行完成后，将使得以太坊进入一个新的状态。状态转变过程中记录了一些起始变量和结果数据，分别是交易默克尔哈希值transactionsRoot、交易回执默克尔哈希值** receiptRoot、事件布隆值logsBloom、新状态的默克尔哈希值stateRoot**。

交易回执

在以太坊中一份交易回执记录了关于此笔交易的处理结果信息：

回执信息分为三部分：共识信息、交易信息、区块信息。下面分别介绍各类信息。

交易回执共识信息

共识意味在在校验区块合法性时，这部分信息也参与校验。这些信息参与校验的原因是确保交易必须在区块中的固定顺序中执行，且记录了交易执行后的状态信息。这样可强化交易顺序。

  • Status： 成功与否，1 表示成功，0 表示失败。
  • CumulativeGasUsed： 区块中已执行的交易累计消耗的 Gas，包含当前交易。
  • Logs: 当前交易执行所产生的智能合约事件列表。
  • Bloom：是从 Logs 中提取的事件布隆过滤器，用于快速检测某主题的事件是否存在于 Logs 中。

如何参与共识校验呢？
实际上参与校验的仅仅是回执哈希，而回执哈希计算只包含这些信息。
首先，在校验时获取整个区块回执信息的默克尔树的根哈希值。再判断此哈希值是否同区块头定义内容相同。

1
2
3
4
5
6
//core/block_validator.go:92
receiptSha := types.DeriveSha(receipts)
if receiptSha != header.ReceiptHash {
   return fmt.Errorf("invalid receipt root hash (remote: %x local: %x)",
   header.ReceiptHash, receiptSha)
}

而函数 types.DeriveSha 中生成根哈希值，是将列表元素（这里是交易回执）的RLP 编码信息构成默克树，最终获得列表的哈希值。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
//core/types/derive_sha.go:32
func DeriveSha(list DerivableList) common.Hash {
   keybuf := new(bytes.Buffer)
   trie := new(trie.Trie)
   for i := 0; i < list.Len(); i++ {
      keybuf.Reset()
      rlp.Encode(keybuf, uint(i))
      trie.Update(keybuf.Bytes(), list.GetRlp(i))
   }
   return trie.Hash()
}
// core/types/receipt.go:237
func (r Receipts) GetRlp(i int) []byte {
   bytes, err := rlp.EncodeToBytes(r[i])
   if err != nil {
      panic(err)
   }
   return bytes
}

继续往下看，交易回执实现了 RLP 编码接口。在方法 EncodeRLP 中是构建了一个私有的 receiptRLP。

1
2
3
4
5
//core/types/receipt.go:119
func (r *Receipt) EncodeRLP(w io.Writer) error {
	return rlp.Encode(w,
	&receiptRLP{r.statusEncoding(), r.CumulativeGasUsed, r.Bloom, r.Logs})
}

从代码中可以看出 receiptRLP 仅仅包含上面提到的参与共识校验的内容。

1
2
3
4
5
6
7
//core/types/receipt.go:78
type receiptRLP struct {
   PostStateOrStatus []byte
   CumulativeGasUsed uint64
   Bloom             Bloom
   Logs              []*Log
}

交易回执交易信息

这部分信息记录的是关于回执所对应的交易信息，有：

  • TxHash ： 交易回执所对应的交易哈希。
  • ContractAddress： 当这笔交易是部署新合约时，记录新合约的地址。
  • GasUsed: 这笔交易执行所消耗的Gas 燃料。

这些信息不参与共识的原因是这三项信息已经在其他地方校验。

  • TxHash: 区块有校验交易集的正确性。
  • ContractAddress： 如果是新合约，实际上已经提交到以太坊状态 State 中。
  • GasUsed： 已属于 CumulativeGasUsed 的一部分。

交易回执区块信息

这部分信息完全是为了方便外部读取交易回执，不但知道交易执行情况，还能方便的指定该交易属于哪个区块中第几笔交易。

  • BlockHash: 交易所在区块哈希。
  • BlockNumber: 交易所在区块高度。
  • TransactionIndex：交易在区块中的序号。

这三项信息，主要是在数据库 Leveldb 中读取交易回执时，实时指定。

1
2
3
4
5
6
7
8
9
10
//core/rawdb/accessors_chain.go:315
receipts := make(types.Receipts, len(storageReceipts))
logIndex := uint(0)
for i, receipt := range storageReceipts {
   //...
   receipts[i] = (*types.Receipt)(receipt)
   receipts[i].BlockHash = hash
   receipts[i].BlockNumber = big.NewInt(0).SetUint64(number)
   receipts[i].TransactionIndex = uint(i)
}

交易回执存储

交易回执作为交易执行中间产物，为了方便快速获取某笔交易的执行明细。以太坊中有跟随区块存储时实时存储交易回执。但为了降低存储量，只存储了必要内容。
首先，在存储时，将交易回执对象转换为精简内容。

1
2
3
4
5
//core/rawdb/accessors_chain.go:338
storageReceipts := make([]*types.ReceiptForStorage, len(receipts))
for i, receipt := range receipts {
   storageReceipts[i] = (*types.ReceiptForStorage)(receipt)
}

精简内容是专门为存储定义的一个结构 ReceiptForStorage。存储时将交易回执集进行 RLP 编码存储。

1
2
3
4
5
6
7
8
//core/rawdb/accessors_chain.go:342
bytes, err := rlp.EncodeToBytes(storageReceipts)
if err != nil {
   log.Crit("Failed to encode block receipts", "err", err)
}
if err := db.Put(blockReceiptsKey(number, hash), bytes); err != nil {
   log.Crit("Failed to store block receipts", "err", err)
}

所以看存储了哪些内容，只需要看 ReceiptForStorage 的 EncodeRLP 方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
//core/types/receipt.go:179
func (r *ReceiptForStorage) EncodeRLP(w io.Writer) error {
   enc := &receiptStorageRLP{
      PostStateOrStatus: (*Receipt)(r).statusEncoding(),
      CumulativeGasUsed: r.CumulativeGasUsed,
      TxHash:            r.TxHash,
      ContractAddress:   r.ContractAddress,
      Logs:              make([]*LogForStorage, len(r.Logs)),
      GasUsed:           r.GasUsed,
   }
   for i, log := range r.Logs {
      enc.Logs[i] = (*LogForStorage)(log)
   }
   return rlp.Encode(w, enc)
}

交易回执示例–文档参考

本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议 ，转载请注明出处！