ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-30 00:25:49 +00:00
Code Issues Packages Projects Releases Wiki Activity

Rename redundant pseudo-transactions index page

Browse Source
This commit is contained in:
mDuo13
2025-10-06 14:27:23 -07:00
parent 259994d74f
commit 07f4436b45
22 changed files with 38 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/concepts/consensus-protocol/negative-unl.md
View File

@@ -72,7 +72,7 @@ Each flag ledger, all of the following changes apply:
1. Changes to the Negative UNL that were scheduled in the previous flag ledger go into effect for the following ledger version. The consensus process for validating this flag ledger itself does not use the scheduled change.
{% admonition type="info" name="Note" %} This is one of the only times a ledger's state data is modified without a [transaction](../transactions/index.md) or [pseudo-transaction](../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md).{% /admonition %}
{% admonition type="info" name="Note" %} This is one of the only times a ledger's state data is modified without a [transaction](../transactions/index.md) or [pseudo-transaction](../../references/protocol/transactions/pseudo-transaction-types/index.md).{% /admonition %}
2. If the Negative UNL is not full, each server proposes adding **up to 1** validator to the Negative UNL from among its trusted validators with less than 50% reliability.
3. If the Negative UNL is not empty, each server proposes removing **up to 1** validator from the Negative UNL. A server can propose removing a validator from the Negative UNL for two reasons:
@@ -80,7 +80,7 @@ Each flag ledger, all of the following changes apply:
- It does not have that validator in its UNL. (If a validator goes down permanently, this rule ensures that it gets removed from the on-ledger Negative UNL after it has been removed from servers' configured UNLs.)
4. If a proposed change to the Negative UNL achieves a consensus, the change is scheduled to go into effect in the following flag ledger. Up to one addition and one removal can be scheduled this way.
The proposals to add and remove validators from the Negative UNL take the form of [UNLModify pseudo-transactions][]. The consensus process determines whether each pseudo-transaction achieves a consensus or gets thrown out, in the same way as other [pseudo-transactions](../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md). In other words, for a particular validator to be added or removed from the Negative UNL, a consensus of servers must propose the same change.
The proposals to add and remove validators from the Negative UNL take the form of [UNLModify pseudo-transactions][]. The consensus process determines whether each pseudo-transaction achieves a consensus or gets thrown out, in the same way as other [pseudo-transactions](../../references/protocol/transactions/pseudo-transaction-types/index.md). In other words, for a particular validator to be added or removed from the Negative UNL, a consensus of servers must propose the same change.
Scheduled and effective changes to the Negative UNL are tracked in the [NegativeUNL object](../../references/protocol/ledger-data/ledger-entry-types/negativeunl.md) in the ledger's state data.