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

The cryptographic seed is a source of randomness for many internal operations inside the protocol.

A formal definition of the seed can be found in the normative specification.

This section provides an engineering and implementation-oriented way of conceptualizing the seed computation, to ease its understanding.

The following algorithm makes heavy use of VRFVRF specific functions. For more information on their definition and internal work, refer to the Algorand Cryptographic Primitive Specification.

For the seed calculation algorithm, consider the following notation:

For the seed calculation algorithm, consider the following pseudocode:

Algorithm 1: Compute Seed and Proof

1: function ComputeSeedAndProof(I)
2:   if p = 0 then
3:     y ← VRF.Prove(Secrets(I) VRF key, L[r−δs]Q)
4:     α ← H(I || VRF.ProofToHash(y))
5:   else
6:     y ← 0
7:     α ← H(L[r−δs]Q)
8:   end if
9:   if r mod (δs δr) < δs then
10:     Q ← H(α || H(L[r−δs δr]))
11:   else
12:     Q ← H(α)
13:   end if
14:   return (Q, y)
15: end function

Important

IMPLEMENTATION: Seed computation reference implementation.

The function takes as input the address II of an online player who will be computing the seed Q.

Note that the player needs to have registered participation keys on the node computing the seed, so as for the Secrets(I) call in Algorithm 1, line 3 to retrieve available VRF secrets generated during that registration process.

For more information on the types of keys a player has to use, refer to the Algorand Participation Key Specification.

The function computes the cryptographic seed appended to the block candidate for round rr, which will be used (if said block candidate is committed) as a source of randomness for the VRF in a future round.

The seed is computed according to whether the function is called in the first period of the round, p = 0, or not.

The function also computes the proof y, bundled up with the block inside a proposal structure (for broadcasting), and used by nodes receiving the proposal as part of the proposal validation process.

The following is an example of seed computation in three adjacent blocks, chosen to show both branches of the Algorithm 1 execution, according to the r mod δs δr condition, also known as re-randomization.

Noting that:

• δs = 2,
• δr = 80.

We define Rerand(r) = r mod δs δr.

When Rerand(r) < δs we say we are re-randomizing the seed Q for the round rr.

Important

EXAMPLE: Take the process for a player with address II at the first consensus attempt of the round (p = 0).

• Let’s consider round ra = 48182880,

Rerand(ra)=48182880 mod 160 = 0 < δs

The computation is:

1. Get the seed Q for round ra−δs=(48182880−2)=48182878,
2. Construct a VRF proof y with that seed,
3. Convert the VRF proof y to a VRF proof hash (named VRFh),
4. Hash the object {I || VRFh} (named α),
5. Lookup the block digest of the old round ra−δsδr=48182880−160=48182720 (named Hold),
6. Calculate the final seed by hashing the object {α, Hold}.

• This process will be the same for rb=48182881 as

Rerand(rb)=48182881 mod 160 = 1 < δs.

• For the round rc=48182882, since

Rerand(rc)=48182882 mod 160 = 2 ≥ δs,

The computation is:

1. Get the seed Q for round rc−δs=(48182882−2)=48182880,
2. Construct a VRF proof y with that seed,
3. Convert the VRF proof y to a VRF proof hash (named VRFh),
4. Hash the object {I || VRFh} (named α),
5. Calculate the final seed by hashing α.

• This process will be the same for rounds 48182883,…,48183039 as Rerand(48182883,…,48183039) > δs.

If during the execution of consensus for a given round, a period p > 0 is observed (i.e., the protocol is performing a new consensus attempt for the same round), steps 2-3-4 change calculating α by hashing the seed of a round r−δs (instead of the object {I || VRFh}). This condition occurs when another proposal for the same round has to be created. In this case, to avoid the possibility of seed manipulation by malicious proposers, their input is excluded from the computation (as the process uses a seed that is δs rounds in the past, outside potential attacker’s influence).