$$ \newcommand \ABFT {\mathrm{ABFT}} \newcommand \Credentials {\mathrm{Credentials}} \newcommand \sk {\mathrm{sk}} \newcommand \VRF {\mathrm{VRF}} $$

General Concepts

The Algorand Agreement Protocol, or Algorand Byzantine Fault Tolerance (\( \ABFT \)), is a consensus mechanism ensuring secure, decentralized agreement on transactions’ ordering and validity in the Algorand blockchain. It tolerates malicious actors as long as less than one-third of the participants are compromised.

The protocol relies on a cryptographic sortition to randomly and verifiably self-select a small, representative group of participants to propose and validate blocks. This randomness ensures security, scalability, and resistance to attacks.

By achieving instant finality, \( \ABFT \) enables Algorand to process transactions efficiently, making it suitable for large-scale, real-time applications.

In each round, a block must be confirmed. In the context of this section, a block is treated as an opaque data packet with two mandatory fields:

• A block hash,
• A randomness seed.

For details on the remaining fields and the structure of a block, please refer to the Ledger’s normative specification and non-normative overview.

The Algorand Agreement Protocol is executed between nodes.

Functionally, an Algorand node “plays” on behalf of every actively participating account whose participation keys are registered for voting.

Each of these accounts can be viewed as an independent player in the protocol, identified by its unique address \( I \) and associated balance.

All the accounts registered on the node share a unified view of the transaction pool and blockchain state, which is maintained by the node through which they participate in the protocol.

Consensus is reached progressively. A round is the primary unit of time in the consensus protocol. Each round aims to agree on a single block to append to the blockchain.

The protocol begins a new round once the previous one has finalized a block.

Credentials

We define a structure \( \Credentials \) for ease of use and readability.

This structure will contain all the necessary fields for identifying a voting player, which includes:

• Address (\( I \)): A unique identifier for the participating account.

• Secret key (\( \sk_r \)): A private key associated with the account, used for cryptographic operations such as signing messages¹.

• \( \VRF \) proof (\( y \)): A cryptographic proof generated using the Verifiable Random Function (\( \VRF \))².

The sets of observed votes \( V \) and proposals \( P \), observed in a given round, are utilized here with the same definition as in the normative specification.

Analogous to these, we define a set of observed bundles \( B \) for a given round, that is built taking subsets of votes in \( V \) according to the rules for a valid bundle specified in the normative specification.

1. The secret key \( \sk \) is round-dependent because it makes use of a two-level ephemeral key scheme under the hood. In the context of this document, this procedure is replaced by an opaque structure that produces the key needed for the round and abstracts away both a signature and verification procedure. ↩

2. Since the sortition hash \( \VRF_{out} \) can be derived from a proof \( y \), we assume that \( \VRF_{out} \) is implicitly available whenever \( y \) is present. ↩