聚合印章
下面將介紹區塊頭extraData字段中AggregatedSeal字段的生成過程
MPA區塊頭結構
目前MAP的區塊頭主要包含以下幾個字段。
// Header represents a block header in the Ethereum blockchain.
type Header struct {
ParentHash common.Hash `json:"parentHash" 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"`
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"`
// BaseFee was added by EIP-1559 and is ignored in legacy headers.
BaseFee *big.Int `json:"baseFeePerGas" rlp:"optional"`
}
chunk header 中的 extraData 字段是 rlp 編碼的結果。 編碼前的結構如下:
如果你想獲取extraData的結構化信息。 只需要對 extraData 32 字節之後的其他字節進行 rlp 解碼。 具體的解碼過程可以參考ExtractIstanbulExtra函數
計算區塊頭的hash
計算區塊頭的哈希需要區塊頭中的所有字段。 但是 extraData 需要特別注意,因為 extraData 的長度會影響 hash 的計算方式。 下面根據extraData的長度分兩種情況進行說明。
extraData 的長度小於 32 字節
區塊頭的哈希就是區塊頭的RLP編碼keccak256哈希。
extraData的長度大於等於32字節
在計算hash之前,我們首先需要對extraData進行解碼,然後將AggregatedSeal的字段設置為空。 這一步的具體操作可以在下面的IstanbulFilteredHeader函數中找到。 之後,對區塊頭的RLP編碼進行keccak256 hash,得到區塊頭的hash。
驗證節點廣播提交消息
驗證者節點廣播提交消息,消息中攜帶CommittedSeal。 AggregatedSeal 中的 Signature 字段是所有收集到的提交消息中的 CommittedSeal 的聚合簽名的結果
生成承諾印章
sub.Digest:區塊的哈希值 sub.View.Round:回合數
Convert hash, round, MsgCommit into bytes and concatenate, I can also get a simple seal. MsgCommit is a constant, its value is 2
上面我們通過拼接塊頭的hash和round和一個固定的MsgCommit得到了一個簡單的印章, 但這還不夠,因為這個印記,任何人都可以生成。 然後我們還需要用驗證者的私鑰對印章進行bls簽名,得到最終的committedSeal
###AggregatedSeal 聚合印章
將所有收集到的消息中的CommittedSeal放入一個二維數組中,第一維存儲 消息列表中消息的索引,第二個維度存儲真實的CommittedSeal。 然後對這個二維數組進行bls聚合簽名。
將 sig 附加到塊頭的 extraData 字段
Last updated
Was this helpful?