Blocks are the core data structure in a blockchain. Each block has a batch of transactions that should be executed. Besides transactions, there are metadata that is crucial to the consensus algorithm, which are stored in block headers. Transactions in XDPoS 2.0 are the same as those in XDPoS 1.0, so this document focuses on block headers. The following sections describe the fields of block headers in XDPoS 2.0.
Block Header's Extra Data
XDPoS 2.0 requires the block header to carry extra consensus data. The extra_data field of the block header is an ideal place for this purpose because it does not cause breaking changes to the header structure. More specifically, we redefined this field, and in this section we first describe the new structure and also introduce the old structure for completeness.
New Fields in Block Header's Extra Data
XDPoS 2.0 requires these new fields in block header's extra data:
| Field name | Type | Description |
|---|---|---|
| Round | integer (int64) | Round is the basic tick of XDPoS2.0' consensus algorithm (chained Hotstuff). Each round has a different and deterministic block proposer (a.k.a. leader) from the master list. This Round is the time when this block is proposed. |
| QuorumCert | QuorumCert (described below) | The quorum certificate (QuorumCert, QC) for the parent block, which consists of the signatures from 2/3 of the master nodes. |
These fields are RLP-encoded as bytes and injected into extra data.
QuorumCert struct
-
Block infos. First, a QuorumCert has all the block infos that a vote contains. The infos include the voted block's hash, round, and block number. These three fields are combined into a structure called
ProposedBlockInfo. - Signatures. Second, it has signatures from 2/3 of the master nodes on these block infos. In practice, it may be a concatenated array of signatures. The signer’s address can be derived from the signature. The signature is secp256k1, which is currently used in XDPoS 1.0. Each signature is 65 bytes.
Extra Data of XDPoS 1.0
The extra data in header of XDPoS 1.0 consists of three parts: vanity, signers, and seal. The table below gives a description for them.
| Bytes | Part | Description | Reason for changing |
|---|---|---|---|
| First 32 bytes | Vanity | Reserved for fixed unique bytes for each master node. | Not used in XDPoS. |
| Middle bytes | Signers | The list of master nodes for the coming epoch, whose addresses are concatenated into one byte-array. Non-empty only in checkpoint headers. | Replaced by header.Validators. |
| Last 65 bytes | Seal | The signature of the block proposer for the block. | Replaced by header.Validator. |
As you can see in the following sections, the signers and seal part are replaced by other fields in the headers. And the vanity part is removed since it is not used. Therefore, we can have a completely new structure of extra data in XDPoS 2.0.
Exsting Header Fields with Updated Definitons
Apart from the extra data, these fields exist in XDPoS 1.0 blocks and we keep these fields but use them in a different way in XDPoS 2.0.
| Field name | Type | Before change | After change | Reason for changing |
|---|---|---|---|---|
| Coinbase | address | It’s all zeros. | Change it to the leader’s (or proposer's) address. | Convenient to query who is the leader. |
| Difficulty | integer (big.Int) | It’s computed in a function calcDifficulty and adaptively changes. | Change it to a constant. | Difficulty is not used in XDPoS 2.0. |
| Validator | bytes | It’s the second signature in XDPoS 1.0. | Change it to the leader’s signature. | The second signature is not used in XDPoS 2.0. |
| Validators | bytes | It’s the M1M2 mapping, and only valid if this block is a checkpoint block. | Change it to the list of master nodes' addresses. The addresses are concatenated into bytes. And it is also only valid if this block is an epoch switch block. If not epoch switch, this is empty bytes. | The M1M2 mapping is not used in XDPoS 2.0. |
Unchanged Fields in Block Headers
These fields are used in the same way as in XDPoS 1.0. No change is needed.
- ParentHash
- UncleHash
- Root
- TxHash
- ReceiptHash
- Bloom
- Number
- GasLimit
- GasUsed
- Time
- MixDigest
- Nonce
- Penalties
Discussion (0)