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

Negative UNL: expand on references, correct concept

Browse Source
This commit is contained in:
mDuo13
2020-10-09 19:29:33 -07:00
parent 1719dde391
commit 15b15b7ac0
11 changed files with 271 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
content/_snippets/pseudo-tx-fields-intro.md Normal file
View File

@@ -0,0 +1,3 @@
## {{currentpage.name}} Fields
In addition to the [common fields](pseudo-transaction-types.html), a {{currentpage.name}} pseudo-transaction uses the following fields:

1
content/_snippets/rippled-api-links.md
View File

@@ -173,6 +173,7 @@
"FlowV2",
"MultiSign",
"MultiSignReserve",
"NegativeUNL",
"OwnerPaysFee",
"PayChan",
"RequireFullyCanonicalSig",

3
content/_snippets/tx-type-links.md
View File

@@ -20,7 +20,8 @@
] %}
{% set pstxtypes = [
"EnableAmendment",
"SetFee"
"SetFee",
"UNLModify"
] %}

124
content/concepts/consensus-network/negative-unl.md
View File

@@ -7,31 +7,125 @@ blurb: Understand how Negative UNL improves the ledger's resilience during parti
---
# Negative UNL
_The Negative UNL feature has a preliminary implementation in `rippled` 1.6.0 so that it can be used in test networks, but is not yet available as an [amendment](amendments.html) to the XRP Ledger protocol. The `NegativeUNL` amendment :not_enabled: may be included in a future XRP Ledger based on acceptance testing of the preliminary implementation._
_The Negative UNL feature has a preliminary implementation in `rippled` 1.6.0 so that it can be used in test networks, but is not yet available as an [amendment](amendments.html) to the XRP Ledger protocol. A `NegativeUNL` amendment :not_enabled: may be included in a future XRP Ledger release based on acceptance testing of the preliminary implementation._
_Negative UNL_ is a feature of the XRP Ledger [consensus protocol](consensus.html) that improves _liveness_, the network's ability to make forward progress during a partial outage. Negative UNL adjusts the _quorum requirements_ based on which validators are currently online and operational, so that a new [ledger version](ledgers.html) can be declared _validated_ even if several trusted validators are offline.
The _Negative UNL_ is a feature of the XRP Ledger [consensus protocol](consensus.html) that improves _liveness_, the network's ability to make forward progress during a partial outage. Using the Negative UNL, servers adjust their effective UNLs based on which validators are currently online and operational, so that a new [ledger version](ledgers.html) can be declared _validated_ even if several trusted validators are offline.
The Negative UNL has no impact on how the network processes transactions or what transactions' outcomes are, except that it improves the network's ability to declare outcomes final during some types of partial outages.
## Background
Each server in the XRP Ledger protocol has its own UNL (Unique Node List), a list of validators it trusts not to collude, and each server independently decides when a ledger version is validated based on the consensus when enough of its trusted validators agree on a new ledger version. (The default configuration uses a recommended UNL, signed by Ripple, consisting of validators Ripple considers to be sufficiently unique, reliable, and independent.) The standard quorum requirement is at least 80% of trusted validators must agree.
## Tracking Offline Validators
Therefore, if more than 20% of trusted validators go offline or become unable to communicate with the rest of the network, the network stops making forward progress because it cannot reach a quorum. This is a design choice to ensure that no transactions' outcomes can be changed after they are declared final. During such a situation, the remaining servers would still be online and could provide past and tentative transaction data, but could not confirm the final, immutable outcome of new transactions.
When one or more validators appear to be offline or nonfunctional, the remaining validators can vote to add that validator to the "negative UNL," a list of trusted validators who appear not to be participating in the consensus process. To take effect, the vote must achieve a consensus in the same way that other [pseudo-transactions](pseudo-transaction-types.html) do. The Negative UNL is tracked in the [TODO ledger object](TODO) in the ledger's state data.
When a validator on the negative UNL appears to come back online, validators vote to remove it from the negative UNL by the same process. Validators also vote to remove untrusted entries from the shared Negative UNL.
However, this means that the network could stop making forward progress if a few widely-trusted validators went offline. As of 2020-10-06, there are 34 validators in Ripple's recommended UNL, so the network would stop making forward progress if 7 or more of them were offline. Furthermore, if one or two validators are out for an extended period of time, the network has less room for disagreement between the remaining validators, which can make it take longer to achieve a consensus.
## Quorum Adjustments
## Summary
When calculating the quorum for a potential ledger version, any offline validators in the previous ledger's Negative UNL don't count toward a server's total number of trusted validators. This can lower the quorum requirement to a smaller number. Trusted validators always count towards the total when they _do_ provide validation votes, regardless of whether they are in the negative UNL.
It is not reasonable to expect a diverse set of validators to maintain 100% uptime: many things can cause a validator to become temporarily unavailable, such as: hardware maintenance, software upgrades, internet connectivity problems, targeted attacks, human error, hardware failures, and outside circumstances like natural disasters.
For example:
The "Negative UNL" is **a list of trusted validators which are believed to be offline or malfunctioning**, as declared by a consensus of the remaining validators. Validators in the Negative UNL are ignored for determining if a new ledger version has attained a consensus.
When a validator that is on the Negative UNL comes back online and sends consistent validation votes, the remaining validators remove it from the Negative UNL after a short time.
In cases where validators go offline one or two at a time, the remaining validators can use the Negative UNL to gradually adjust their effective UNLs, so that the network only ever needs 80% of the _online_ validators to achieve a quorum. To prevent the network from fragmenting, the quorum has a hard minimum of 60% of _total_ validators.
The Negative UNL does not help against situations where greater than 20% of trusted validators suddenly go offline all at once. In that case, the remaining validators would not be able to reach the consensus necessary to adjust the Negative UNL.
## How It Works
The Negative UNL is closely tied to the [consensus process](consensus.html) and is designed with safeguards to maintain the continuity and reliability of the network in adverse situations. When all trusted validators are operating normally, the Negative UNL is unused and has no effect. When some validators appear to be offline or out of sync, the Negative UNL rules take effect.
The Negative UNL is intentionally designed to change at a slow rate, to avoid any time-based disagreements about which Negative UNL should apply to a given ledger version's consensus process.
### Reliability Measurement
Each server in the network has a UNL, the list of validators it trusts not to collude. (By default, a server's exact UNL is configured implicitly based on the recommended validator list Ripple publishes.) Each server tracks the _reliability_ of its trusted validators using a simple metric: the percentage of the last 256 ledgers where the validator's validation vote matched the server's view of consensus. In other words:
> Reliability = V<sub>a</sub> ÷ 256
V<sub>a</sub> is the total number of validation votes received for the last 256 ledgers that matched the server's own view of consensus.
This metric of reliability measures the availability of a validator _and_ the behavior of that validator. A validator should have a high reliability score if it is in sync with the rest of the network and following the same protocol rules as the server scoring it. A validator's reliability score can suffer for any of the following reasons:
- The validator's validation votes are not reaching the server due to poor network connectivity between them.
- The validator stops operating or gets overloaded.
- The validator is not following the same protocol rules as the server, for a variety of reasons. Possibilities include misconfiguration, software bugs, intentionally following a [different network](parallel-networks.html), or malicious behavior.
If a validator's reliability is **less than 50%**, it is a candidate to be added to the Negative UNL. To be removed from the Negative UNL, a validator's reliability must be **greater than 80%**.
Each server, including validators, independently calculates reliability scores for all of its trusted validators. Different servers may reach different conclusions about a validator's reliability, either because that validator's votes reached one server and not the other, or because they happened to disagree about specific ledgers more or less often. To add or remove a validator from the Negative UNL, a consensus of trusted validators must agree that a particular validator is above or below the reliability threshold.
### Modifying the Negative UNL
A ledger version is considered a _flag ledger_ if its ledger index is evenly divisible by 256. The Negative UNL can be modified only on flag ledgers. (Flag ledgers occur about once every 15 minutes on the XRP Ledger Mainnet. They may be farther apart in test networks that have low transaction volume.)
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.
**Note:** This is one of the only times a ledger's state data is modified without a [transaction](transaction-basics.html) or [pseudo-transaction](pseudo-transaction-types.html).
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:
- It scores that validator with > 80% reliability.
- 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 achieve 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](pseudo-transaction-types.html). 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](negativeunl.html) in the ledger's state data.
### Negative UNL Limits
To prevent the network from fragmenting into two two or more sub-networks, the Negative UNL cannot reduce the quorum requirement to less than 60% of the _total_ UNL entries. To enforce this, a server considers the Negative UNL to be "full" if the number of validators on the Negative UNL is 25% (rounded down) of the number of validators in the server's configured UNL. (The 25% is based on the calculation that if 25% of validators are removed, an 80% consensus of the remaining 75% equals 60% of the original number.)
### Choosing From Multiple Candidate Validators
It is possible that multiple validators may be candidates to be added to the Negative UNL. Since at most one validator can be added to the Negative UNL at a time, servers must choose which validator to propose adding. If there are multiple candidates, the server chooses which one to propose with the following mechanism:
1. Start with the ledger hash of the parent ledger version.
0. Take the public key of each candidate validator that is past the reliability threshold.
0. Calculate the exclusive-or value (XOR) of the candidate validator and the parent ledger's hash.
0. Propose the validator the numerically lowest result of the XOR operation.
If there are multiple candidates to be removed from the Negative UNL in a given flag ledger, servers use the same mechanism to choose among them.
This mechanism has several useful properties:
- It uses information that is readily available to all servers and can be calculated quickly.
- Most servers will chose the same result even if they calculated slightly different scores for their trusted validators. This holds even if those servers disagree on which validator is _least_ or _most_ reliable. This even holds in many cases where the servers disagree on whether some validators are above or below the reliability thresholds. Therefore, the network is likely to achieve a consensus on which validator to add or remove.
- It does not always give the same results each ledger version. Therefore, if one proposed change to the Negative UNL fails to achieve a consensus, the network does not get stuck with some servers trying and failing to add or remove that one validator every time. The network can attempt to add or remove a different candidate to the Negative UNL in a later flag ledger.
### Filtering Validations
During the consensus process, validators in the parent ledger's Negative UNL (**TODO: parent ledger? validation status?**) are disabled. Each server calculates an "effective UNL" consisting of its configured UNL with the disabled validators removed, and recalculates its quorum accordingly. If a disabled validator sends validation votes, other servers listen to those for purposes of calculating its reliability measurement, but they do not use those votes towards determining whether a ledger version has achieved a consensus.
**Note:** The Negative UNL adjusts the _total_ trusted validators that the quorum is calculated from, not the quorum directly. The quorum is a percentage but the number of votes is a whole number, so in some cases, reducing the total trusted validators may not change the number of votes required to reach a quorum. For example, if there are 15 total validators, 80% is 12 validators exactly. If you reduce the total to 14 validators, 80% is 11.2 validators, which means that it still requires 12 validators to reach a quorum.
### Example
**TODO: maybe a diagram or animation would help to visualize this?**
The following example demonstrates how the Negative UNL affects the consensus process:
1. Suppose your server's UNL consists of 38 trusted validators, so an 80% quorum is at least 31 of 38 trusted validators.
2. Imagine 2 of those validators, named MissingA and UnsteadyB, appear to have gone offline. During the consensus process for ledger _N_, many of the remaining validators propose adding MissingA and UnsteadyB to the negative UNL. The motion passes via a quorum of at least 31 of the remaining validators, and ledger _N_ becomes validated.
3. For ledger _N+1_, both MissingA and UnsteadyB continue to be offline. Neither one provides a validation vote, so both are subtracted from the total 38 validators. The adjusted quorum requirement is therefore 80% of 36 = 28.8; so, ledger _N+1_ can be validated by a quorum of as few as 29 validators.
4. For ledger _N+2_, UnsteadyB comes back and provides a validation vote. Therefore, it counts toward the total number of trusted validators. MissingA is still offline, so the working quorum is 80% of 37 validators = 29.6. Ledger _N+2_ can be validated with a quorum of 30 validators or more.
5. After UnsteadyB has been back online for a while, the validators vote to remove it from the Negative UNL.
6. Eventually, you decide that MissingA is probably not coming back, so you remove it from your server's UNL. Your server no longer consider's MissingA's vote for validating new ledger versions.
7. As validator operators remove MissingA from their UNLs, their validators vote to also remove MissingA from the Negative UNL. When enough validators have done so, the pseudo-transaction to remove MissingA achieves a consensus and becomes validated.
2. Imagine 2 of those validators, named MissingA and UnsteadyB, appear to have gone offline. (Both of them have reliability scores < 50%.) During the consensus process for ledger _N_, many of the remaining validators propose adding UnsteadyB to the negative UNL. The motion passes via a quorum of at least 31 of the remaining validators, and ledger _N_ becomes validated with UnsteadyB scheduled to be disabled.
3. For ledgers _N+1_ through _N+256_, the consensus process continues without changes.
4. In the next flag ledger, ledger _N+256_, UnsteadyB gets automatically moved from "scheduled" to the "disabled" list in the ledger. Also, since MissingA is still offline, a consensus of validators schedules MissingA to be disabled in the next flag ledger.
5. For ledgers _N+257_ through _N+512_, the quorum is now 30 of 37 validators.
6. UnsteadyB comes back online in ledger _N+270_. It sends validation votes that agree with the rest of the network for ledgers _N+270_ through _N+511_, giving it a reliability score of > 80%.
7. In the next flag ledger, _N+256_, MissingA gets automatically moved to the disabled list, as scheduled. Meanwhile, a consensus of validators schedule UnsteadyB to be removed from the Negative UNL.
8. For ledgers _N+513_ through _N+768_, the quorum is 29 of 36 validators. UnsteadyB continues to send validations stably while MissingA remains offline.
9. In flag ledger _N+768_, UnsteadyB gets automatically removed from the disabled list, as scheduled.
10. Eventually, you decide that MissingA is probably not coming back, so you remove it from your server's configured UNL. Your server starts proposing removing MissingA from the Negative UNL each flag ledger thereafter.
11. As validator operators remove MissingA from their configured UNLs, their validators vote to also remove MissingA from the Negative UNL. When enough validators have done so, the proposal to remove MissingA achieves a consensus, and MissingA is scheduled, then finally removed from the Negative UNL.

2
content/references/rippled-api/ledger-data-formats/ledger-object-types/ledgerhashes.md
View File

@@ -3,7 +3,7 @@
(Not to be confused with the ["ledger hash" string data type][Hash], which uniquely identifies a ledger version. This section describes the `LedgerHashes` ledger object type.)
The `LedgerHashes` object type contains a history of prior ledgers that led up to this ledger version, in the form of their hashes. Objects of this ledger type are modified automatically in the process of closing a ledger. (This is the only time the ledger's "state" tree is modified without a transaction or pseudo-transaction.) The `LedgerHashes` objects exist to make it possible to look up a previous ledger's hash with only the current ledger version and at most one lookup of a previous ledger version.
The `LedgerHashes` object type contains a history of prior ledgers that led up to this ledger version, in the form of their hashes. Objects of this ledger type are modified automatically in the process of closing a ledger. (This is one of the only times a ledger's state data is modified without a [transaction](transaction-basics.html) or [pseudo-transaction](pseudo-transaction-types.html).) The `LedgerHashes` objects exist to make it possible to look up a previous ledger's hash with only the current ledger version and at most one lookup of a previous ledger version.
There are two kinds of `LedgerHashes` object. Both types have the same fields. Each ledger version contains:

61
content/references/rippled-api/ledger-data-formats/ledger-object-types/negativeunl.md Normal file
View File

@@ -0,0 +1,61 @@
---
html: negativeunl.html
funnel: Build
doc_type: References
supercategory: rippled API
category: Ledger Data Formats
subcategory: Ledger Object Types
blurb: List of validators currently believed to be offline.
---
# NegativeUNL
The `NegativeUNL` object type contains the current status of the [Negative UNL](negative-unl.html), a list of trusted validators currently believed to be offline.
Each ledger version contains **at most one** `NegativeUNL` object. If no validators are currently disabled or scheduled to be disabled, there is no `NegativeUNL` object in the ledger.
## Example {{currentpage.name}} JSON
```json
{
"DisabledValidators": [
{
"DisabledValidator": {
"FirstLedgerSequence": 1609728,
"PublicKey": "ED6629D456285AE3613B285F65BBFF168D695BA3921F309949AFCD2CA7AFEC16FE"
}
}
],
"Flags": 0,
"LedgerEntryType": "NegativeUNL",
"index": "2E8A59AA9D3B5B186B0B9E0F62E6C02587CA74A4D778938E957B6357D364B244"
}
```
A `NegativeUNL` object has the following fields:
| Name | JSON Type | [Internal Type][] | Description |
|:----------------------|:----------|:------------------|:---------------------|
| `LedgerEntryType` | String | UInt16 | The value `0x004E`, mapped to the string `NegativeUNL`, indicates that this object is the Negative UNL. |
| `DisabledValidators` | Array | Array | _(May be omitted)_ A list of `DisabledValidator` objects (see below), each representing a trusted validator that is currently disabled. |
| `ValidatorToDisable` | String | Blob | _(May be omitted)_ The public key of a trusted validator that is scheduled to be disabled in the next flag ledger. |
| `ValidatorToReEnable` | String | Blob | _(May be omitted)_ The public key of a trusted validator in the Negative UNL that is scheduled to be re-enabled in the next flag ledger. |
## DisabledValidator Objects
Each DisabledValidator Object represents one disabled validator. In JSON, a DisabledValidator object has one field, `DisabledValidator`, which in turn contains another object with the following fields:
| Name | JSON Type | [Internal Type][] | Description |
|:----------------------|:----------|:------------------|:---------------------|
| `FirstLedgerSequence` | Number | UInt32 | The [ledger index][] when the validator was added to the Negative UNL. |
| `PublicKey` | String | Blob | The master public key of the validator, in hexadecimal. |
## NegativeUNL ID Format
The `NegativeUNL` object ID is the hash of the `NegativeUNL` space key (`0x004E`) only. This means that the ID of the `NegativeUNL` object in a ledger is always:
```
2E8A59AA9D3B5B186B0B9E0F62E6C02587CA74A4D778938E957B6357D364B244
```

29
content/references/rippled-api/transaction-formats/pseudo-transaction-types/enableamendment.md
View File

@@ -1,19 +1,42 @@
# EnableAmendment
Tracks the progress of the [amendment process](amendments.html#amendment-process) for changes in transaction processing. This can indicate that a proposed amendment gained or lost majority approval, or that an amendment has been enabled.
An `EnableAmendment` [pseudo-transaction](pseudo-transaction-types.html) marks a change in status of an [amendment](amendments.html) to the XRP Ledger protocol, including:
- A proposed amendment gained supermajority approval from validators.
- A proposed amendment lost supermajority approval.
- A proposed amendment has been enabled.
**Note:** You cannot send a pseudo-transaction, but you may find one when processing ledgers.
## Example {{currentpage.name}} JSON
```json
{
"Account": "rrrrrrrrrrrrrrrrrrrrrhoLvTp",
"Amendment": "42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE",
"Fee": "0",
"LedgerSequence": 21225473,
"Sequence": 0,
"SigningPubKey": "",
"TransactionType": "EnableAmendment"
}
```
{% include '_snippets/pseudo-tx-fields-intro.md' %}
<!--{# fix md highlighting_ #}-->
| Field | JSON Type | [Internal Type][] | Description |
|:-----------------|:----------|:------------------|:--------------------------|
| `Amendment` | String | Hash256 | A unique identifier for the amendment. This is not intended to be a human-readable name. See [Amendments](amendments.html) for a list of known amendments. |
| `LedgerSequence` | Number | UInt32 | The index of the ledger version where this amendment appears. This distinguishes the pseudo-transaction from other occurrences of the same change. |
| `LedgerSequence` | Number | UInt32 | The [ledger index][] where this pseudo-transaction appears. This distinguishes the pseudo-transaction from other occurrences of the same change. |
## EnableAmendment Flags
The `Flags` value of the EnableAmendment pseudo-transaction indicates the status of the amendment at the time of the ledger including the pseudo-transaction.
A `Flags` value of `0` (no flags) indicates that the amendment has been enabled, and applies to all ledgers afterward. Other `Flags` values are as follows:
A `Flags` value of `0` (no flags) or an omitted `Flags` field indicates that the amendment has been enabled, and applies to all ledgers afterward. Other `Flags` values are as follows:
| Flag Name | Hex Value | Decimal Value | Description |
|:-----------------|:-------------|:--------------|:---------------------------|

30
content/references/rippled-api/transaction-formats/pseudo-transaction-types/pseudo-transaction-types.md
View File

@@ -1,13 +1,25 @@
# Pseudo-Transactions
Pseudo-Transactions are never submitted by users, nor propagated through the network. Instead, a server may choose to inject them in a proposed ledger directly. If enough servers inject an equivalent pseudo-transaction for it to pass consensus, then it becomes included in the ledger, and appears in ledger data thereafter.
Pseudo-transactions are never submitted by users, nor [propagated through the network](peer-protocol.html). Instead, a server may choose to inject pseudo-transactions in a proposed ledger directly according to specific protocol rules. If enough servers inject an identical pseudo-transaction for it to be approved by the [consensus process](consensus.html), then the pseudo-transaction becomes included in the ledger, and appears in ledger data thereafter.
Some of the fields that are mandatory for normal transactions do not make sense for pseudo-transactions. In those cases, the pseudo-transaction has the following default values:
## Special Values for Common Fields
| Field | Default Value |
|:----------------|:--------------------------------------------------|
| `Account` | [ACCOUNT_ZERO](accounts.html#special-addresses) |
| `Sequence` | `0` |
| `Fee` | `0` |
| `SigningPubKey` | `""` |
| `Signature` | `""` |
Some of the required [common fields][] for normal transactions do not make sense for pseudo-transactions. Pseudo-transactions use following special values for these common fields:
| Field | JSON Type | [Internal Type][] | Value |
|:----------------|:----------|:------------------|:---------------------------|
| `Account` | String | AccountID | [ACCOUNT_ZERO](accounts.html#special-addresses) |
| `Fee` | String | Amount | `0` |
| `Sequence` | Number | UInt32 | `0` |
| `SigningPubKey` | String | Blob | `""` (Empty string) |
| `SigningPubKey` | String | Blob | `""` (Empty string) |
Pseudo-transactions use the following common fields as normal:
- `TransactionType`
- `Flags`
| Field | JSON Type | [Internal Type][] | Description |
|:------------------|:----------|:------------------|:-------------------------|
| `TransactionType` | String | UInt16 | _(Required)_ The type of transaction. |
| `Flags` | Number | UInt32 | _(Optional)_ A set of bit-flags for this transaction. The meaning of specific flags varies based on the transaction type. |

11
content/references/rippled-api/transaction-formats/pseudo-transaction-types/setfee.md
View File

@@ -1,10 +1,12 @@
# SetFee
A change in [transaction cost](transaction-cost.html) or [account reserve](reserves.html) requirements as a result of [Fee Voting](fee-voting.html).
A `SetFee` [pseudo-transaction](pseudo-transaction-types.html) marks a change in [transaction cost](transaction-cost.html) or [reserve requirements](reserves.html) as a result of [Fee Voting](fee-voting.html).
**Note:** You cannot send a pseudo-transaction, but you may find one when processing ledgers.
```
## Example {{currentpage.name}} JSON
```json
{
"Account": "rrrrrrrrrrrrrrrrrrrrrhoLvTp",
"BaseFee": "000000000000000A",
@@ -18,9 +20,12 @@ A change in [transaction cost](transaction-cost.html) or [account reserve](reser
"date": 439578860,
"hash": "1C15FEA3E1D50F96B6598607FC773FF1F6E0125F30160144BE0C5CBC52F5151B",
"ledger_index": 3721729,
}
}
```
{% include '_snippets/pseudo-tx-fields-intro.md' %}
<!--{# fix md highlighting_ #}-->
| Field | JSON Type | [Internal Type][] | Description |
|:--------------------|:-----------------|:------------------|:----------------|
| `BaseFee` | String | UInt64 | The charge, in drops of XRP, for the reference transaction, as hex. (This is the [transaction cost](transaction-cost.html) before scaling for load.) |

38
content/references/rippled-api/transaction-formats/pseudo-transaction-types/unlmodify.md Normal file
View File

@@ -0,0 +1,38 @@
# UNLModify
A `UNLModify` [pseudo-transaction](pseudo-transaction-types.html) marks a change to the [Negative UNL](negative-unl.html), indicating that a trusted validator has gone offline or come back online.
**Note:** You cannot send a pseudo-transaction, but you may find one when processing ledgers.
## Example {{currentpage.name}} JSON
```json
{
"Account": "",
"Fee": "0",
"LedgerSequence": 1600000,
"Sequence": 0,
"SigningPubKey": "",
"TransactionType": "UNLModify",
"UNLModifyDisabling": 1,
"UNLModifyValidator": "ED6629D456285AE3613B285F65BBFF168D695BA3921F309949AFCD2CA7AFEC16FE",
}
```
## {{currentpage.name}} Fields
{% include '_snippets/pseudo-tx-fields-intro.md' %}
<!--{# fix md highlighting_ #}-->
| Name | JSON Type | [Internal Type][] | Description |
|:---------------------|:----------|:------------------|:----------------------|
| `TransactionType` | String | UInt16 | The value `0x0066`, mapped to the string `UNLModify`, indicates that this object is an `UNLModify` pseudo-transaction. |
| `LedgerSequence` | Number | UInt32 | The [ledger index][] where this pseudo-transaction appears. This distinguishes the pseudo-transaction from other occurrences of the same change. |
| `UNLModifyDisabling` | Number | UInt8 | If `1`, this change represents adding a validator to the Negative UNL. If `0`, this change represents removing a validator from the Negative UNL. (No other values are allowed.) |
| `UNLModifyValidator` | String | Blob | The validator to add or remove, as identified by its master public key. |
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

1
tool/spelling.txt
View File

@@ -159,6 +159,7 @@ trustset
trustsetauth
tx_history
unl
UNLModify
unls
wallet_propose
v0