Consensus Rounds - The Voting Process

When consensus begins, each validator has a candidate set:

INITIAL STATE (simplified example):

Validator V1's candidates: {Tx_A, Tx_B, Tx_C, Tx_D}
Validator V2's candidates: {Tx_A, Tx_B, Tx_E}
Validator V3's candidates: {Tx_A, Tx_C, Tx_D, Tx_F}
Validator V4's candidates: {Tx_A, Tx_B, Tx_C}
Validator V5's candidates: {Tx_A, Tx_D, Tx_E, Tx_F}

- Tx_A: All 5 validators (100%)
- Tx_B: V1, V2, V4 (60%)
- Tx_C: V1, V3, V4 (60%)
- Tx_D: V1, V3, V5 (60%)
- Tx_E: V2, V5 (40%)
- Tx_F: V3, V5 (40%)

The goal: Converge on a set that achieves 80% agreement.

Each validator broadcasts its proposal:

PROPOSAL MESSAGE:

{
  "type": "proposal",
  "validator": "nHU...",
  "ledger_sequence": 85000001,
  "transactions": [hash_A, hash_B, hash_C, hash_D],
  "close_time": 1699999999,
  "signature": "..."
}

• Proposals contain transaction hashes, not full transactions
• Full transactions were already shared during collection
• This keeps proposal messages small
• Validators sign proposals to prove authenticity

After receiving proposals, each validator counts support:

VOTE COUNTING (from V1's perspective):

Transaction | V1 | V2 | V3 | V4 | V5 | Total | Percentage
------------|----|----|----|----|----| ------|----------
Tx_A        | ✓  | ✓  | ✓  | ✓  | ✓  |   5   |   100%
Tx_B        | ✓  | ✓  |    | ✓  |    |   3   |    60%
Tx_C        | ✓  |    | ✓  | ✓  |    |   3   |    60%
Tx_D        | ✓  |    | ✓  |    | ✓  |   3   |    60%
Tx_E        |    | ✓  |    |    | ✓  |   2   |    40%
Tx_F        |    |    | ✓  |    | ✓  |   2   |    40%

(Assuming V1-V5 are in V1's UNL)

---

A fixed threshold creates problems:

Problem with Fixed 50% Threshold:

Tx_X has exactly 50% support
Round 1: Include (≥50%)
Round 2: Some validators drop it, now 48%
Round 3: Exclude (<50%)
Round 4: Some add it back, now 52%
Round 5: Include (≥50%)
... oscillation continues forever

Problem with Fixed 80% Threshold:

Tx_Y has 70% support
Never achieves 80%
But 70% is substantial agreement
Forcing exclusion seems wrong
Network might never agree

XRPL uses increasing thresholds:

THRESHOLD ESCALATION:

- Include if ≥50% propose
- Exclude if <50% propose

- Include if ≥60% propose
- Exclude if <40% propose
- Disputed if 40-60%

- Include if ≥70% propose
- Exclude if <30% propose
- Disputed if 30-70%

- Include if ≥80% propose
- Everything else excluded or deferred

- Low initial threshold: Generous inclusion
- Rising threshold: Forces decisions
- Final 80%: Strong agreement required
- Disputed transactions: Deferred, not rejected forever

Let's trace our example through rounds:

ROUND 1 (50% threshold):

Tx_A: 100% → INCLUDE
Tx_B: 60%  → INCLUDE
Tx_C: 60%  → INCLUDE
Tx_D: 60%  → INCLUDE
Tx_E: 40%  → DISPUTED (borderline)
Tx_F: 40%  → DISPUTED (borderline)

After Round 1: {Tx_A, Tx_B, Tx_C, Tx_D} + disputed {Tx_E, Tx_F}

ROUND 2 (60% threshold):

Validators update proposals based on Round 1 results
Some drop Tx_E, Tx_F from proposals
Some add them hoping others will too

New counts:
Tx_A: 100% → INCLUDE
Tx_B: 65%  → INCLUDE
Tx_C: 60%  → INCLUDE (borderline)
Tx_D: 55%  → DISPUTED
Tx_E: 35%  → EXCLUDE
Tx_F: 30%  → EXCLUDE

After Round 2: {Tx_A, Tx_B, Tx_C} + disputed {Tx_D}

ROUND 3 (70% threshold):

Tx_A: 100% → INCLUDE
Tx_B: 75%  → INCLUDE
Tx_C: 68%  → DISPUTED
Tx_D: 45%  → EXCLUDE

After Round 3: {Tx_A, Tx_B} + disputed {Tx_C}

ROUND 4 (80% threshold):

Tx_A: 100% → INCLUDE
Tx_B: 82%  → INCLUDE
Tx_C: 55%  → EXCLUDE (doesn't meet 80%)

FINAL SET: {Tx_A, Tx_B}

Transactions that don't make the final set aren't rejected forever:

EXCLUDED TRANSACTION HANDLING:

- Remains in validators' candidate pools
- Will be proposed again for ledger 85000002
- May achieve consensus next round
- Only truly rejected if:

- Same process
- Might make next ledger
- Might never achieve consensus
- Eventually expire (LastLedgerSequence)

---

Each consensus round has timing constraints:

TIMING PARAMETERS (approximate):

- Validators send initial proposals
- Allow time for network propagation

- Collect peer proposals
- Recalculate positions
- Send updated proposals

- 2-4 rounds: 2-3 seconds
- Edge cases: Up to ~10 seconds

Consensus is achieved when:

CONVERGENCE CRITERIA:

1. Transaction Set Agreement

1. Close Time Agreement

1. No Disputed Transactions

When all criteria met: CONSENSUS ACHIEVED

The protocol is designed for convergence:

• If most others include Tx_X, add it

• If most others exclude Tx_Y, drop it

• Natural tendency toward agreement

• Can't stay disputed forever

• Must either achieve 80% or get excluded

• Eventually, a set emerges

• Close times rounded to nearest second

• Minor skew doesn't prevent consensus

• All validators target same rounded time

Certain conditions can slow convergence:

High Transaction Volume:

More transactions = more potential disagreement
More rounds needed to resolve disputes
Still converges, just takes longer

Network Issues:

Delayed proposals = outdated information
Validators may make conflicting decisions
Additional rounds needed to reconcile

Validator Downtime:

Missing validators = fewer proposals
Thresholds calculated on available validators
Negative UNL helps maintain progress

Byzantine Behavior:

Up to 20% Byzantine: Consensus continues
Byzantine validators may cause extra rounds
But cannot prevent convergence

---

Transaction ordering affects outcomes:

ORDERING EXAMPLE:

Alice has 100 XRP
Tx1: Alice sends 100 XRP to Bob
Tx2: Alice sends 100 XRP to Carol

If Tx1 executes first: Bob gets 100, Tx2 fails
If Tx2 executes first: Carol gets 100, Tx1 fails

Order determines outcome!

XRPL uses deterministic ordering:

ORDERING RULES:

1. Sort by account sequence number

1. Then by transaction hash

Result: Given same transaction set,
        all validators compute same execution order

Unlike some systems, XRPL's ordering is largely deterministic:

FRONT-RUNNING ANALYSIS:

- Order determined by sequence numbers and hashes
- No validator can arbitrarily reorder
- Limited manipulation opportunity

- Miners can reorder within blocks
- Creates front-running opportunities
- XRPL's model is more resistant

- Validators who receive transactions first
- Not a significant issue in practice

---

When transactions conflict:

CONFLICT RESOLUTION:

Tx1: Alice sends 100 XRP to Bob (signed at T1)
Tx2: Alice sends 100 XRP to Carol (signed at T2)

Both valid individually
Both cannot execute

- Both may enter consensus rounds
- Both may be in initial proposal
- During execution: First by sequence/hash wins
- Second fails with "tecPATH_DRY" or similar
- Transaction fee still charged

If consensus takes too long:

TIMEOUT HANDLING:

- Validators may adjust proposals more aggressively
- Drop disputed transactions
- Force convergence on minimal agreed set
- Remaining transactions deferred

- Safety preserved (no conflicting ledgers)
- Some transactions delayed
- Next ledger starts promptly

Transactions can specify expiration:

LASTLEDGERSEQUENCE FIELD:

{
  "TransactionType": "Payment",
  "LastLedgerSequence": 85000005,
  ...
}

- Transaction must be included by ledger 85000005
- If not included by then: Permanently rejected
- Prevents stale transactions executing later
- Recommended practice for all submissions

If a transaction doesn't make consensus:

RETRY STRATEGY:

1. Set LastLedgerSequence (current + ~4)
2. Submit transaction
3. Wait for result or expiration
4. If expired: Resubmit with fresh parameters

1. Submit with longer LastLedgerSequence window
2. Transaction will retry automatically
3. Eventually included or fails for other reasons

---

The consensus rounds ensure safety:

SAFETY ANALYSIS:

Claim: Two honest validators cannot finalize different transaction sets

- Both use 80% threshold for finalization
- UNL overlap >90% required
- Any two 80% sets from overlapping UNLs must share honest validators
- Honest validators don't validate conflicting sets
- Therefore: Conflicting sets cannot both achieve 80%

Result: Safety guaranteed (given UNL overlap)

The consensus rounds ensure liveness:

LIVENESS ANALYSIS:

Claim: Consensus will eventually be reached

- Threshold escalation forces decisions
- Disputed transactions eventually excluded
- Final round accepts only 80%+ agreement
- At worst: Empty transaction set (always achievable)

Result: Consensus always possible (may be empty set)

Up to 20% Byzantine validators are tolerated:

BYZANTINE BEHAVIOR IN ROUNDS:

- Propose conflicting sets to different validators
- Refuse to propose
- Propose invalid transactions
- Change proposals randomly

- More rounds may be needed
- Some transactions may be delayed
- But cannot:

---

XRPL's consensus rounds are elegantly designed. The escalating threshold mechanism solves the convergence problem without a leader, achieving agreement in 2-4 rounds typically. The process is robust to minority Byzantine behavior and guarantees safety. The main limitation is that disputed transactions may be delayed—but this is inherent to leaderless consensus. For most practical purposes, the 3-5 second typical convergence is excellent.

---

Assignment: Work through three consensus scenarios manually to understand round mechanics.

Requirements:

• Trace through rounds until consensus

• Show vote counts at each round

• Identify final transaction set

• Calculate number of rounds needed

• Trace through threshold escalation

• Show which transactions are included/excluded at each threshold

• Document what happens to excluded transactions

• Identify final set

• Analyze how honest validators handle conflicting information

• Show how consensus still converges

• Identify the impact of Byzantine behavior

• Calculate how many Byzantine validators could break consensus

• Accuracy of round calculations (40%)

• Understanding of threshold mechanics (30%)

• Analysis of Byzantine scenario (20%)

• Clarity of presentation (10%)

Time investment: 2-3 hours
Value: Manual simulation builds intuition for consensus mechanics that reading alone cannot provide.

---

For Next Lesson:
Lesson 10 examines what happens after consensus—the validation phase where validators confirm they all computed the same ledger state. This is the final step before finality.

---

End of Lesson 9

Total words: ~5,200
Estimated completion time: 55 minutes reading + 2-3 hours for deliverable

---

Teaching Philosophy:
This is the most technical lesson so far. The worked examples are essential—abstract descriptions of "threshold escalation" don't convey understanding like tracing actual numbers through rounds. The simulation deliverable reinforces this hands-on learning.

Deliverable Purpose:
Manual simulation forces students to internalize the mechanics. By calculating vote counts and tracking transactions through rounds, students develop intuition that passive reading cannot provide.

Lesson 10 Setup:
After consensus on transaction set, validators must confirm they computed the same resulting ledger state. Lesson 10 explains this validation phase—the final step before finality.