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 Update function is called each time a new block is confirmed.

During this process, the TxPool removes all transactions that have either already been committed or whose lastValid field has expired.

The adjustment of the fee prioritization mechanism depends on how many full blocks are currently pending in the TxPool queue.

The state of the TxPool is then updated as follows:

Algorithm 3: Update TxPool

1: function Update(newBlock b, stateDeltas d)
2:    if TxPool is empty or outdated then
3:        switch TxPool.pendingFullBlocks
4:            case 0:
5:                feeThresholdMultiplier ← FeeMul FeeExp
6:            case 1:
7:                Intentionally left blank to maintain the value of feeThresholdMultiplier
8:            case default:
9:                if feeThresholdMultiplier = 0 then
10:                   feeThresholdMultiplier ← 1
11:               else
12:                   feeThresholdMultiplier ← feeThresholdMultiplier ⋅ expFeeFactor
13:               end if
14:       end switch
15:   end if
16:   TxPool.Prune(b, d)
17: end function

IMPLEMENTATION: Update on a new block reference implementation.

The algorithm above updates the feeThresholdMultiplier based on the current state of the pending queue. Specifically, it checks whether the queue is either empty (no leftover transactions from the previous block assembly) or outdated (i.e., the remaining transactions were grouped into full blocks from a round r such that r ≥ r_p, where r is the current round).

The adjustment logic works as follows:

• If there are 0 pending full blocks: This suggests that any previous congestion has cleared. The feeThresholdMultiplier is reduced by dividing it by the expFeeFactor. If this low-congestion state continues, the multiplier quickly diminishes and approaches 0.

• If there is exactly 1 pending full block: The feeThresholdMultiplier remains unchanged.

• Otherwise, if there are more than 1 pending full block (TxPool.pendingFullBlocks > 1):

  • If the feeThresholdMultiplier is currently 0, it is set to 1 to reflect a sudden spike in congestion.
  • If it already has a value, it is multiplied by the expFeeFactor, causing it to grow in response to continued congestion.

After updating the fee prioritization mechanism, the TxPool is pruned by removing:

• Transactions that were included in the newly committed block b, and
• Transactions whose lastValid field is less than the current round (which matches the round of b that was just observed).