Skip to content

Blocks

A block is a set of Transactions paired with various metadata necessary to link the block into a proof-of-work blockchain.

The lifecycle of a block begins when a miner draws a set of transactions from its Transaction Pool, initializes the metadata fields, and begins grinding the nonce. Once a suitable nonce has been found, the miner broadcasts the block to its peers. Each peer node then validates the block against the current State, and applies it to produce the new state. Finally, the block and its effects are handed off to any non-consensus subsystems (such as a wallet whose balance might be impacted by the block's transactions).

The non-transaction fields are as follows:

  • ParentID: The hash of the previous block in the chain.
  • Nonce: An arbitrary number used by miners. Altering the nonce alters the block hash; miners thus "grind nonces" in the hopes of finding a block hash that meets the current proof-of-work target.
  • Timestamp: The approximate time at which the block was mined. This is what makes Difficulty Adjustment possible.
  • Miner Address: The address that will receive the block reward, plus any transaction fees.
  • Height: The height of the block, i.e. its 0-indexed position in the chain.
  • Commitment: A hash of the block's parent State, transaction data, and miner address.

The hash of a block is known as its ID. Note that the actual data hashed— the "preimage"—is not the block itself, but rather its "header," which is formed by concatenating the ParentID, Nonce, Timestamp, and Commitment. Since altering any of these fields would also alter the block's ID, we say that they are "covered" by the ID. (Note that this property applies recursively: everything covered by the Commitment hash is also covered by the block ID.) This means that if you are given an ID, you can trustlessly acquire that block's parent state as well, by asking a peer or an explorer, and verifying that you can recover the block ID from that state.

In fact, the only pieces of information in a block that are not directly covered by its ID are the Commitment (which would be impossible) and the Height (which mainly exists for developer convenience). However, these fields are checked for correctness during Block Validation, and the height of the parent block is covered (via the parent State).

Since proof-of-work can be validated from just the header, it is possible to download and validate just the headers of the chain, in what is known as "headers-first syncing." When combined with trustless state acquisition, this enables Sia's "Instant Sync".

In v1

Prior to the v2 Require Height, blocks could also contain v1 transactions. Prior to the Allow Height, blocks could only contain v1 transactions, and also lacked Height and Commitment fields. Furthermore, v1 headers did not include the parent State in their Commitment; instead, only the block's miner payouts (of which there could be more than one) and the block's transactions were covered.