Block Header - Algorand Specifications

Keyboard shortcuts

Press ← or → to navigate between chapters
Press S or / to search in the book
Press ? to show this help
Press Esc to hide this help

Algorand Specifications

An Algorand Ledger can be minimally defined by a sequence of block headers linked
by the prevHash field, as the header contains a cryptographic commitment to
the contents of the block body (the payset).

The following diagram illustrates the minimal Ledger definition:

A string and a 32-byte array, respectively.

They ensure the block belongs to the correct blockchain. These match the genesis
information about the chain’s state.

Important
EXAMPLE:
For the MainNet:

Cryptographic commitment (hash) of the previous block header, linking blocks into
a chain. The genesis block has this field set to 00.

A 64-bit unsigned integer value that identifies the block’s round. The genesis
block has round 00. For all other cases, it must be equal to the round of
the previous block plus one (that is, they must be sequential and monotonically
increasing).

A 32-byte array holding a random value used as a seed for cryptographic processes
(e.g., block proposer selection).

The seed calculation algorithm (see ABFT normative specification)
defines implicitly a sequence of seeds, whose values alternate according to:

Important
EXAMPLE:
Example a valid seed chain computation.

A 64-bit unsigned integer.

The timestamp is purely informational and states when a block was proposed, expressed
in seconds since UNIX Epoch (00:00:00
Thursday, 1 January 1970, at UTC).

The difference between consecutive timestamps cannot be greater than tδ=25tδ=25
seconds

See the formal definition in the Ledger normative specification.

Important
EXAMPLE:
In the reference implementation, checks on the timestamp are performed during
block assembly. See the MakeBlock
function.

Consensus protocol does not guarantee the accuracy of the timestamp!

Cryptographic commitments (hash) to the block’s transaction sequence. Internally,
it uses a Merkle Tree and commits to the tree’s root.

Two different hashes are provided:

Important
IMPLEMENTATION:
Transactions (payset) commit reference implementation.

The amount in μALGO paid to the proposer is the sum of a fee component and a bonus
component. The payout is subject to eligibility criteria and protocol limits.

For further details, refer to the rewards non-normative specification.

Total transaction fees collected in the block expressed in μALGO.

A potential extra reward component of the block proposer payout, in addition to the
fee component, expressed in μALGO. Subject to change during upgrades and to decrease
every millionth round, according to an exponential decay curve.

Address of the account that proposed this block.

A structure representing the reward state. It contains the following fields:

A 32-byte array holding a constant address. This address collects transaction fees
and pays block rewards.

Important
EXAMPLE:
MainNet FeeSink address: Y76M3MSY6DKBRHBL7C3NNDXGS5IIMQVQVUAB6MP4XEMMGVF2QWNPL226CA.

This legacy rewards distribution mechanism is currently inactive. See the non-normative\
section for further details on the active reward
mechanism.

A 32-byte array holding a constant address. This address pays distribution rewards
(legacy system, currently inactive).

Important
EXAMPLE:
MainNet RewardsPool address: 737777777777777777777777777777777777777777777777777UFEJ2CI.

A 64-bit unsigned integer holding the amount of μALGO distributed to each participant
account since the genesis block.

A 64-bit unsigned integer indicating the amount of μALGO added to the participation
stake from the RewardsPool in the next round (legacy system, currently set to 00 for every block).

A 64-bit unsigned integer holding the leftover amount of μALGO after the distribution
of RewardsRateRewardUnitsRewardsRateRewardUnits for every reward unit in the next round.

A 64-bit unsigned integer holding the round at which the RewardsRateRewardsRate will
be recalculated.

A 64-bit unsigned integer counting transactions committed before this block. It
is initialized at 00 or 10001000 in the genesis block, depending on the AppForbidLowResources consensus parameter.

This field tracks the protocol upgrade state machine. It contains a link to the
currently active version of this specification.

A link to the commit in the Algorand Formal Specification repository
of the currently active protocol version.

A link to the commit in the Algorand Formal Specification repository
of a new protocol version being voted on.

An uint64 integer that represents the vote count for a next protocol upgrade.
Set to 0 unless a vote is ongoing.

Round number at which the next protocol would be adopted. Set to 0 unless a vote
is ongoing.

Round number before which a vote for the next protocol version should be issued
and computed. Set to 0 unless a vote is ongoing.

This field represents the vote of the block proposer on the new protocol version.

It contains two fields:

A boolean flag that indicates an affirmative vote for the new protocol version.
Usually set to false unless a protocol upgrade vote is ongoing.

The delay in rounds between the approval of a new protocol version and its execution.
Usually set to 00 unless an upgrade vote is ongoing.

A structure with two optional fields:

An optional list of account addresses to be removed from consensus participation,
due to expired participation keys (from the end of this round). Limited to 3232
accounts.

An optional list of online account addresses to be removed from consensus participation,
due to long-lasting absenteeism in the expected block proposals. Limited to 3232
accounts.