Weighted Trust for UNL Nodes

[trixky]

Title:       Weighted Trust for UNL Nodes
Authors:     Mathis Bois
Created:     2025-08-13

Weighted Trust for UNL Nodes

Abstract

This proposal introduces a trust weighting system for validator nodes in the Unique Node List (UNL), allowing each node to be assigned a trust weight instead of the current binary 0 or 1 model. This system supports weights from 0.0 to 2.0 (or higher), enabling both gradual trust building for new validators and enhanced trust for long-established, highly reliable nodes. This aims to enhance flexibility in consensus trust modeling, facilitate smoother validator onboarding, and better reflect real-world dynamics of node trustworthiness.

Motivation

In the current XRPL consensus model, the UNL acts as a binary trust system: a validator is either trusted (weight = 1) or not trusted (weight = 0). While this model is simple and robust, it lacks the granularity needed for:

• Gradual introduction of new validators with lower initial trust
• Enhanced trust for long-established validators with proven track records
• Recognition of validators operated by well-known, highly trusted entities
• Reflecting real-world variations in trust due to operator history, performance, uptime, or stake in the ecosystem

Notably, the upcoming Cobalt consensus implementation already considers weighted trust in its design. This proposal aligns the current model with that future direction, ensuring forward compatibility and easing migration.

---

Specification

Trust Weight Definition

Each validator in the UNL will be associated with a trust weight, a floating-point value representing the degree of trust attributed to that node. While the standard range is 0.0 to 2.0, the system can accommodate higher values if needed.

Weight Value	Trust Level	Description
0.0	No Trust	Equivalent to exclusion from the UNL
0.1 - 0.9	Progressive Trust	Gradual trust building for new validators
1.0	Standard Trust	Equivalent to current UNL inclusion
1.1 - 2.0	Enhanced Trust	For long-established, highly reliable validators
> 2.0	Exceptional Trust	Reserved for critical infrastructure nodes

Enhanced Trust Rationale

Weights above 1.0 are justified for validators that:

• Have operated reliably for multiple years without significant downtime
• Are operated by well-known, trusted entities in the XRPL ecosystem
• Have demonstrated exceptional performance and reliability metrics
• Provide critical infrastructure services to the network
• Have strong operational security and governance practices

Backward Compatibility

• If a validator has no specified weight, it is assumed to be 1.0 (standard trust)
• Current UNL files and APIs will remain valid
• An updated format will be defined to optionally include trust weights

Consensus Integration

Consensus decisions will factor in trust weight by modifying how vote counts are aggregated:

• Thresholds for consensus (e.g., 80%) will be evaluated against weighted vote sums, not simple validator counts
• Vote aggregation formula: total_weighted_votes = Σ(validator_vote × trust_weight)
• High-trust validators (weight > 1.0) have proportionally greater influence on consensus

Example Use Cases

Scenario	Initial Weight	Final Weight	Rationale
New validator operator	0.25	1.0 (gradual increase)	Prove reliability over time
Trusted institutional validator	1.0	1.0	Standard institutional trust
Long-established validator (3+ years)	1.0	1.5-2.0	Proven long-term reliability
Ripple-operated validator	1.0	2.0	Core infrastructure, known entity
Exchange-operated validator (major)	1.0	1.5	High stakes, good reputation
Flaky node	1.0	0.5	Temporary downgrade without removal

---

Rationale

While the UNL system is already, philosophically, a weighted trust mechanism (presence = 1, absence = 0), this proposal generalizes that idea and opens the door to smoother validator management with enhanced granularity.

Benefits:

• Reflects real-world trust models more accurately
• Recognizes and rewards long-term, reliable validators
• Allows critical infrastructure to have appropriate influence
• Prepares the network for future consensus innovations such as Cobalt
• Enables gradual validator onboarding and offboarding
• Provides finer-grained control over consensus participation

Trust Building Process:
A validator's weight can evolve over time:
0.25 → 0.5 → 0.75 → 1.0 → 1.25 → 1.5 → 2.0

---

Drawbacks

• Complexity: Adds complexity to UNL management and consensus computations
• Governance: Potential disagreements about how trust weights should be assigned and changed
• Centralization Risk: High-weight validators could potentially have too much influence
• Compatibility: Requires validator operators and clients to upgrade to support the new format

---

Risk Mitigation

Centralization Concerns

• Weight Caps: Maximum weight could be capped (e.g., 2.0) to prevent excessive centralization
• Distribution Requirements: Guidelines ensuring no single entity controls too much weighted trust
• Transparency: Public reporting of weight assignments and rationale

Governance Framework

• Community Input: Weight changes above 1.0 require community discussion
• Performance Metrics: Objective criteria for weight increases (uptime, latency, etc.)
• Regular Review: Periodic reassessment of all weights based on recent performance

---

Prior Art

System	Weighted Trust Mechanism
Cobalt	Ripple's next-gen consensus implementation includes support for weighted trust
Tendermint / Cosmos	Uses validator voting power based on stake (can be > 1x base weight)
Ethereum PoS	Uses validator weight based on ETH stake (32 ETH increments)

---

Future Work

• Tools for visualizing and editing weighted UNLs
• APIs for querying validator trust weights
• Governance framework for weight management
• Performance analysis and optimization of weighted consensus calculations
• Objective metrics system for determining weight increases

---

Context and Acknowledgments

This XLS proposal was conceived and developed during the Core Dev Bootcamp held in July 2025 in Paris, organized by the XRPL Commons Foundation. The collaborative environment and intensive hands-on training provided the perfect setting for exploring advanced consensus mechanisms and protocol improvements.

The idea matured through discussions with fellow developers and instructors, particularly benefiting from the deep technical expertise and guidance available during the bootcamp. The structured learning environment, which covered everything from blockchain fundamentals to advanced rippled architecture, provided the necessary foundation for understanding the complexities of weighted trust systems.

Acknowledgments

I would like to express my gratitude to:

• Denis Angell - @dangell7, Core Developer at XRPL Labs and Program Manager of the Core Dev Bootcamp, whose expertise and guidance were invaluable throughout the development of this proposal
• Vytautas Vito Tumas - @Tapanito, PhD, Blockchain Researcher and Software Engineer, whose presentation during the bootcamp and the subsequent discussions were inspiring and helped fuel the reflection on this topic
• The entire XRPL Foundation team for their continued support of the ecosystem and educational initiatives
• Luc Sanglas - @Saint-luc, a friend and fellow bootcamp participant who took the time to thoroughly read the entire Cobalt research paper and discovered that the weighted trust system was already discussed in the paper, providing crucial insights that shaped this proposal

[mvadari]

• Are these values included as a part of the UNL or determined dynamically by a node?
• What is the threshold for consensus now? 80% now doesn't really mean anything if we're supposed to be weighting.
• Does the weighting apply to amendment voting as well? If so, what is the threshold for that?

[mvadari]

A couple more questions:

• Is there a restriction to the number of decimal points a value can have? Can I give a validator a weight of $pi/2$ ?
• Is the idea that the list owner would set these weights or that each user of the list would set their own weights?

[dangell7]

1. The UNL can still provide a default but it would be on the operators to come up with their own weights.
2. Still 80%. A Quorum is created the same way.
3. Yes, its still 80%

In a 10 validator UNL you can weigh the nodes so that 2 nodes are worth 4 and so you either need those 2 or one of those and 4 other nodes...

4. Yeah its 2 decimal place in the implementation I believe.
5. Each node

[xVet]

Can you describe how this plays on reserve and fee voting too?

I'd have assumed to see that different trust levels open up different weighted access for things to vote on.

E.g amendment voting only for highest tier and perhaps base fee medium tier etc.

[dangell7]

Essentially, weighted and unweighted average are the same. There's only a difference in how you count.

[mvadari]

I have changed this to a pre-proposal since it seems to still be in an early stage and doesn't have the level of detail on the consensus/implementation side needed for a full proposal.

[shortthefomo]

can we get an explanation of how sybil attacks are addressed via this proposal, would like to understand that more here.

Distribution Requirements: Guidelines ensuring no single entity controls too much weighted trust

was briefly touched here

[trixky]

There will basically not be much difference from the current system (especially if you set everyone's trust weight to 1). This system might even add better resistance if you increase the points of the nodes you trust, since the new nodes will default to 1. But this fundamentally does not solve the original problem.

[m1ndh4x]

Weight scheduling?

[trixky]

Yes, that would be really great!
It's definitely something we should move towards. Perhaps by giving the host the choice to choose their trust evolution strategy/algo. But because that adds automation, we should be very careful not to create security holes with bad scenarios.