The Negative UNL - Handling Offline Validators

The Negative UNL is a list of validators temporarily excluded from quorum calculations:

NEGATIVE UNL CONCEPT:

Normal UNL: {V1, V2, V3, V4, V5, ..., V35}
Negative UNL: {V8, V15} (validators deemed unreliable)

Effective UNL: Normal UNL - Negative UNL
            = {V1, V2, V3, V4, V5, ..., V35} - {V8, V15}
            = 33 validators

- 80% of Effective UNL (33) = 27 validators
- Not 80% of original UNL (35) = 28 validators

The name comes from set subtraction:

NAMING LOGIC:

Positive list: Validators you trust (UNL)
Negative list: Validators to exclude (nUNL)

Effective validators = Positive - Negative

It's a "negative" because you're subtracting,
not because anything is bad about the validators.

The key feature: adjustment is automatic:

AUTOMATIC ADJUSTMENT:

- Validator offline → Network slows/stalls
- Manual intervention to remove validator
- Coordination required
- Slow response

- Validator offline → System detects
- Validator added to nUNL automatically
- Quorum adjusts automatically
- No manual intervention needed

---

Validators are scored for reliability:

RELIABILITY MEASUREMENT:

- Did they send a validation in recent ledgers?
- Did their validation agree with consensus?
- How consistent is their participation?

- High reliability: Consistent, agreeing validations
- Low reliability: Missing validations, disagreement

- Below 50% reliability: Candidate for nUNL addition
- Above 80% reliability: Candidate for nUNL removal

Process for adding validators to nUNL:

ADDITION PROCESS:

1. Detection

1. Proposal

1. Consensus

1. Activation

Process for removing validators from nUNL:

REMOVAL PROCESS:

1. Recovery

1. Reliability Improvement

1. Proposal

1. Consensus

1. Restoration

The Negative UNL is stored on-ledger:

LEDGER OBJECT:

{
  "LedgerEntryType": "NegativeUNL",
  "DisabledValidators": [
    {
      "DisabledValidator": {
        "FirstLedgerSequence": 85000000,
        "PublicKey": "nHU..."
      }
    },
    ...
  ],
  "ValidatorToDisable": "nHX...",
  "ValidatorToReEnable": null
}

- DisabledValidators: Currently in nUNL
- ValidatorToDisable: Pending addition
- ValidatorToReEnable: Pending removal

---

The Negative UNL has a critical safety limit:

SAFETY FLOOR:

Quorum can never drop below 60% of original UNL

- Original 80% threshold: 28 validators
- Minimum possible threshold: 21 validators (60%)
- Maximum nUNL size: 35 - (21/0.8) ≈ 9 validators

- Effective UNL: 26 validators
- 80% of 26 = 21 validators
- This equals 60% of original 35
- CANNOT add more to nUNL

The 60% floor prevents safety violations:

60% FLOOR RATIONALE:

- Could reduce quorum arbitrarily low
- Eventually, small minority could control network
- Safety guarantees eroded

- Always need majority of original validators
- Prevents hostile takeover via validator dropoff
- Maintains meaningful Byzantine tolerance

- If >25% of validators fail: Network stalls
- But: Network doesn't become insecure
- Stall is recoverable; compromise isn't

Mathematical derivation:

FLOOR CALCULATION:

Goal: Ensure nUNL can't compromise safety

- n = original UNL size
- k = nUNL size
- Effective UNL = n - k
- Effective quorum = 0.8 × (n - k)

- Effective quorum ≥ 0.6 × n
- 0.8 × (n - k) ≥ 0.6 × n
- n - k ≥ 0.75 × n
- k ≤ 0.25 × n

Result: nUNL can contain at most 25% of original UNL

When nUNL is "full":

FULL nUNL SCENARIO:

35 validators, nUNL at 25% capacity (8-9 validators)

- Cannot add to nUNL (full)
- That validator's votes still expected
- Network may struggle to reach quorum

- nUNL can't adapt fast enough
- Network likely stalls
- Manual intervention needed

---

Best case for Negative UNL:

GRADUAL FAILURE (1-2 validators per week):

Week 0: 35 validators, nUNL empty
Week 1: V8 goes offline, detected, added to nUNL
        Effective: 34, quorum: 28
Week 2: V15 goes offline, added to nUNL
        Effective: 33, quorum: 27
Week 3: V22 goes offline, added to nUNL
        Effective: 32, quorum: 26
...
Week 8: 8 validators in nUNL (near limit)
        Effective: 27, quorum: 22

Network continues throughout
Gradual adjustment maintains liveness

Challenging case:

SUDDEN FAILURE (many validators at once):

T+0: 35 validators, nUNL empty
T+1min: Power outage takes down 10 validators simultaneously

- nUNL can only add validators gradually
- Can't instantly add all 10
- Meanwhile, only 25 validators available
- Need 28 for consensus (80% of 35)
- Network stalls

- As nUNL catches up, effective quorum drops
- Eventually: effective UNL = 25, quorum = 20
- But nUNL at capacity (8-9)
- If still only 25 available, network continues
- If <21 available, network stalls until recovery

What if Byzantine validators pretend to be offline?

BYZANTINE SCENARIO:

7 Byzantine validators (20% of 35)
Collude to appear offline

- All 7 stop sending validations
- Get added to nUNL
- Effective UNL drops to 28

- Return, looking legitimate
- Get removed from nUNL

- Now 100% of effective UNL is "reliable"
- Byzantine validators regained status

- Doesn't increase their voting power
- Still only 7/35 = 20% of original
- Can't achieve 80% even of reduced set
- Attack doesn't work

Safety preserved because Byzantine tolerance
is calculated on original UNL, not effective.

Partition handling:

NETWORK PARTITION SCENARIO:

Network splits: Group A (20 validators), Group B (15 validators)

- Has 20 validators
- Needs 28 for consensus (80% of 35)
- nUNL can't reduce below 60% = 21
- Even with max nUNL: need 21
- Has 20, can't achieve 21
- Group A stalls

- Has 15 validators
- Same math, worse situation
- Group B stalls

- Both halves stall
- Neither can validate independently
- This is correct behavior (safety preserved)
- Reunited network resumes

---

The nUNL updates gradually:

UPDATE RATE:

- Add 1 validator to nUNL
- Remove 1 validator from nUNL
- Net change: -1 to +1 per ledger

- Prevents rapid manipulation
- Allows other validators to observe
- Gives time for detection of issues

- Minimum 8 ledgers to add 8 validators
- ~30 seconds minimum to reach full nUNL

Changes require agreement:

nUNL CHANGE CONSENSUS:

- Multiple validators must propose adding V
- Must achieve consensus like any ledger change
- Recorded in ledger state

- Single validator manipulating nUNL
- Rapid unilateral changes
- Disagreement on who's in nUNL

How servers calculate effective quorum:

EFFECTIVE QUORUM:

1. Load current nUNL from ledger state
2. Compute effective UNL = UNL - nUNL
3. Compute quorum = 80% of effective UNL
4. Ensure quorum ≥ 60% of original UNL

- Original UNL: 35 validators
- nUNL: {V8, V15, V22} (3 validators)
- Effective UNL: 32 validators
- Quorum: 26 validators (80% of 32)
- Check: 26 ≥ 21 (60% of 35) ✓

Use 26 as quorum for this ledger.

What validator operators should know:

OPERATOR IMPLICATIONS:

- Extended downtime → nUNL addition
- Loss of voting power while in nUNL
- Reputation impact

- Come back online, send validations
- Achieve >80% reliability
- Get removed from nUNL (takes time)

- Maximize uptime
- Communicate planned downtime
- Monitor your reliability score
- Have redundancy plans

What users should understand:

USER IMPLICATIONS:

- nUNL works silently in background
- User experience unchanged
- Transactions process normally

- If many validators offline, latency may increase
- Consensus may take longer
- But safety maintained

- Major outage might cause delays
- Network won't produce invalid ledgers
- Patience required until recovery

Assessing network risk:

RISK FACTORS:

- nUNL empty or small
- All validators healthy
- Normal operation

- nUNL approaching capacity
- Several validators struggling
- Close monitoring warranted

- nUNL at capacity
- More validators showing issues
- Network may stall
- Consider delaying large transactions

---

The Negative UNL is an elegant mechanism that allows XRPL to maintain liveness under moderate validator failures while preserving safety through hard limits. It handles the common case (gradual validator issues) well but has clear limits for catastrophic failures. The 60% floor is a crucial safety constraint that prevents the mechanism from being used to compromise the network. This is sophisticated engineering that balances competing requirements thoughtfully.

Assignment: Model three validator failure scenarios and analyze Negative UNL behavior.

Requirements:

• Start with 35 validators, nUNL empty

• One validator goes offline every week for 10 weeks

• Track: nUNL size, effective UNL, quorum requirement each week

• Calculate: At what point does network become fragile?

• Start with 35 validators, nUNL empty

• 12 validators go offline simultaneously

• Track: Immediate impact, nUNL adaptation over time

• Calculate: How long until network can continue (if ever)?

• Start with network at nUNL capacity (8-9 validators in nUNL)

• All offline validators come back online simultaneously

• Track: How quickly does nUNL empty?

• Calculate: Time to full recovery

Include calculations showing quorum requirements at each stage.

• Accuracy of calculations (40%)
• Understanding of nUNL mechanics (30%)
• Quality of analysis and insights (20%)
• Clarity of presentation (10%)

Time investment: 2-3 hours
Value: Working through scenarios builds intuition for network resilience properties.

For Next Lesson:
Lesson 12 completes Phase 2. Lesson 13 begins Phase 3: Security & Comparison, examining attack vectors against XRPL consensus.

End of Lesson 12

End of Phase 2: XRPL Mechanics

Total words: ~4,500
Estimated completion time: 45 minutes reading + 2-3 hours for deliverable

Teaching Philosophy:
The Negative UNL is elegant engineering that students often overlook. It demonstrates that XRPL designers thought carefully about failure modes. The calculations make the concepts concrete.

Deliverable Purpose:
Working through scenarios with actual calculations builds intuition. Students understand not just what the nUNL does but what its limits are.