The Algorand blockchain uses a decentralized Byzantine agreement protocol based on pure proof-of-stake (PPoS). It works as follows:

• Participation:
  • Every online user who possesses ALGOs can participate in the consensus protocol.
  • To reduce exposure, users do not use their spending keys (i.e., the keys they use to spend stake) for consensus. Instead, a user who wishes to participate in the protocol generates and registers a participation key.
  • With this key, an account can participate in proposing and voting on blocks. Using participation keys ensures that a user’s ALGOs are secure even if their participating node is compromised.
• Selection via Verifiable Random Function:
  • Every block in Algorand reveals a new random and unpredictable selection seed that determines which users should participate in the next round of the consensus protocol.
  • When a new block gets committed to the blockchain, everyone becomes aware of this seed (and everyone sees the same seed).
  • A user secretly checks whether they were selected to participate by evaluating a Verifiable Random Function (VRF) with their secret participation key and the selection seed.
  • This computation is minimal, so even a limited device such as a Raspberry Pi can do it.
  • The VRF computation produces a pseudorandom output with a cryptographic proof that anyone can use to verify the result. By sending this proof, a user can prove to anyone that they were indeed selected to participate.
  • Users are chosen to participate in the protocol based on the stake (number of ALGOs) that they have. The VRF behaves similarly to a weighted lottery. The more ALGOs in an online account, the better chance the account has of being selected to participate.
  • The selection of users to participate in the certification of blocks using the VRF is done randomly and secretly, without any communication among the users. Since executing this procedure requires a user’s private key, no one except for that user knows whether they were selected.
  • An adversary does not know who matters in generating the next block (and thus should be targeted) until after a selected user participates in the consensus protocol. And by the time an adversary realizes that a user is selected, it is too late for them to benefit from an attack; the user has already sent their message and fulfilled their responsibility in the consensus protocol.
  •  Furthermore, for each step of the protocol, a unique subset of participants is randomly and privately selected, independent of earlier subsets.
• Soft vote:
  • Each node will run the VRF for every participating account it manages to see if they have been chosen to participate in the soft vote committee.
  • Each account chosen will filter the proposals down to one by voting to confirm the block. These votes will be for the lowest VRF block proposal calculated at the timeout and will be sent out to the other nodes along with the VRF proof.
  • Each node will validate the committee membership VRF proof before adding it to the vote tally. Once a quorum is reached for the soft vote, the process moves to the certify vote step.
• Certify vote:
  • A new committee is then selected to check the block proposal that was voted on in the soft vote phase for overspending, double-spending, or any other problems. If valid, the committee votes again to certify the block.
  •  This is done in a similar manner to the soft vote where each node iterates through its managed accounts to select a committee and to send votes.
  • These votes are collected and validated by each node until a quorum is reached, triggering an end to the round and prompting the node to create a certificate for the block and write it to the ledger.