A Nimiq block can exist in two modes: full and light. A light block is equal to a full block, but does not have a body. A Nimiq block can be at most 1MB (1 million bytes) maximum and is composed of (body optional):
|Body||>= 117||If switch is
The header has total size of 146 bytes and is composed of:
|previous hash||Hash||32||Hash of previous block|
|body hash||Hash||32||Cf. body hash and body|
|accounts hash||Hash||32||Root hash of PM tree storing accounts state, cf. account tree|
|nBits||bits||4||Minimum difficulty for Proof-of-Work|
|height||uint32||4||Blockchain height when created|
|timestamp||uint32||4||When the block was created|
|nonce||uint32||4||Needs to fulfill Proof-of-Work difficulty required for this block|
At main net launch time, version will be “1” and hashes in the header will be based on Blake2b.
The expressions “block hash” and “block header hash” refer to the same hash. The hash is used to refer to the previous block in the blockchain. It’s created using Blake2b on the serialized block header of the previous block as pre-image.
The interlink implements the Non Interactive Proofs of Proof of Work (NiPoPow) and contains links to previous blocks.
An interlink is composed of:
|count||uint8||1||Up to 255 blocks can be referred|
|repeat bits||bit map||ceil(count/8)||So duplicates can be skipped. See below.|
|hashes||[Hash]||<= count * 32||Hashes of referred blocks|
Repeat bits is a bit mask corresponding to the list of hashes, a 1-bit indicating that the hash at that particular index is the same as the previous one, i.e. repeated, and thus the hash will not be stored in the hash list again to reduce size. As each hash is represented by one bit the size is ceil(count/8).
hashes are a list of up to 255 block hashes of 32 bytes each.
Thus, an interlink can be up to 1+ceil(255/8)+255*32 = 8193 bytes.
The concept of Non-Interactive Proofs of Proof-of-Work are used to create the interlink.
An interlink contains hashes to previous blocks with a higher-than-target difficulty. The position of a hash in the interlink correlates to how much higher the difficulty was compared to the target difficulty.
An interlink is created based on the interlink of the previous block plus putting the current hash into place.
- The block’s hash will be placed into the beginning of the new interlink as many times as it is more difficult than the required difficulty.
- The remaining places of the new interlink will be filled by the hashes of the previous interlink, keeping the position.
Finally, the interlink is compressed by counting and skipping repeating hashes.
The body part is 25 bytes plus data, transactions, and prunded accounts:
|miner address||Address||20||Recipient of the mining reward|
|extra data length||uint8||1|
|extra data||raw||extra data length||For future use|
|transactions||[Transaction]||~150 each||Transactions mined in this block|
|pruned accounts count||uint16||2|
|pruned accounts||Pruned Account||each >= 20+8||Accounts with balence
Transactions can be basic or extended. Basic uses 138 bytes, extended more than 68 bytes. Transactions need to be in block order (first recipient, then validityStartHeight, fee, value, sender). Pruned accounts by their address.
The body hash is generated by calculating the root of a Merkle Tree with following leaves:
extra data, each
Transaction, and each
Pruned Account (in this order).
A pruned account is composed of an account of any type with an address:
|address||Address||20||Address of account|
|account||Account||>9||Can be a basic account, vesting contract, or HTLC|
This type is used in the body of a block to communicate the accounts to be pruned with this block.