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

• Auto
• Light
• Dark

Algorand Specifications

A block is a data structure that specifies the transition between states.

The data in a block is divided between the block header and its block body.

The block header contains the following components:

The block’s round, which matches the round of the state it is transitioning into. (The block with round 00 is special in that this block specifies not a transition but rather the entire initial state, which is called the genesis state. This block is correspondingly called the genesis block). The round is stored under msgpack key rnd.

The block’s genesis identifier and genesis hash, which match the genesis identifier and hash of the states it transitions between (i.e., they stay constant since the initial state forwards). The genesis identifier is stored under msgpack key gen, and the genesis hash is stored under msgpack key gh.

The block’s upgrade vote, which results in the new upgrade state. The block also duplicates the upgrade state of the state it transitions into. The msgpack representations of the upgrade vote components are described in detail below.

The block’s timestamp, which matches the timestamp of the state it transitions into. The timestamp is stored under msgpack key ts.

The block’s seed, which matches the seed of the state it transitions into. The seed is stored under msgpack key seed.

The block’s reward updates, which results in the new reward state. The block also duplicates the reward state of the state it transitions into. The msgpack representations of the reward updates components are described in detail below.

Cryptographic commitments to the block’s transaction sequence, described below (referred also as payset), using:

• SHA-512/256 hash function, stored under msgpack key txn;

• SHA-256 hash function, stored under msgpack key txn256;

• SHA512 hash function, stored under msgpack key txn512.

The block’s previous hash, which is the cryptographic hash of the previous Block Header in the sequence, using:

• SHA-512/256 hash function, stored under msgpack key prev;

• SHA512 hash function, stored under msgpack key prev512.

The previous hash of the genesis block is 00).

The block’s transaction counter, which is the total number of transactions issued prior to this block. This count starts from the first block with a protocol version that supports the transaction counter. The counter is stored in msgpack field tc.

The block’s proposer, which is the address of the account that proposed the block. The proposer is stored in msgpack field prp.

The block’s fees collected is the sum of all fees paid by transactions in the block and is stored in msgpack field fc.

The potential bonus incentive is the amount, in μALGO, that may be paid to the proposer of this block beyond the amount available from fees. It is stored in msgpack field bi. It may be set during a consensus upgrade, or else it must be equal to the value from the previous block in most rounds, or be 99%99% of the previous value (rounded down) if the round of this block is 0modBb,decay0modBb,decay.

The proposer payout is the actual amount that is moved from the IfIf to the proposer, and is stored in msgpack field pp. If the proposer is not eligible, as described below, the proposer payout MUST be 00. The proposer payout MUST NOT exceed

• The sum of the bonus incentive and half of the fees collected.
• The fee sink balance minus bminbmin.

The block’s expired participation accounts, which contains an optional list of account addresses. These accounts’ participation key expire by the end of the current round, with exact rules below. The list is stored in msgpack key partupdrmv.

The block’s suspended participation accounts, which contains an optional list of account addresses. These accounts have not recently demonstrated that they are available and participating, with exact rules below. The list is stored in msgpack key partupdabs.

A proposer is eligible for bonus payouts if the account’s IncentiveEligible flag is true and its online balance is between Ar,minAr,min and Ar,maxAr,max.

The expired participation accounts list is valid as long as:

• The participation keys of all the accounts in the slice are expired by the end of the round;
• The accounts themselves would have been online at the end of the round if they were not included in the list;
• The number of elements in the list is less than or equal to BNe,maxBNe,max. A block proposer may not include all such accounts in the list and may even omit the list completely.

The suspended participation accounts list is valid if, for each included address, the account is:

• Online;
• Incentive eligible;
• Either absent or failing a challenge as of the current round.

An account is absent if its LastHeartbeat and LastProposed rounds are both more than 20n20n rounds before current, where nn is the reciprocal of the account’s fraction of online stake.

An account is failing a challenge if:

• The first hbbitshbbits bits of the account’s address matches the first hbbitshbbits bits of an active challenge round’s block seed;
• The active challenge round is between hbgracehbgrace and 2hbgrace2hbgrace rounds before the current round.

An active challenge round is a round that is 0modhbr0modhbr.

The length of the list MUST not exceed BNa,maxBNa,max.

A block proposer MAY NOT include all such accounts in the list and MAY even omit the list completely.

The block body is the block’s transaction sequence (also known as payset), which describes the sequence of updates (transactions) to the account state and box state.

A block is valid if each component is also valid. (The genesis block is always valid).

Applying a valid block to a state produces a new state by updating each of its components.

The rest of this document defines block validity and state transitions by describing them for each component.