mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-04 03:45:49 +00:00
Rename redundant pseudo-transactions index page
This commit is contained in:
mDuo13
@@ -74,7 +74,7 @@ En cada flag ledger, se aplican todos los siguientes cambios:
|
||||
|
||||
1. Los cambios la UNL negativa que se programaron en el flag ledger anterior entran en vigencia para la siguiente versión del ledger. El proceso de consenso para validar este flag ledger en sí mismo no utiliza el cambio programado.
|
||||
|
||||
**Nota:** Esto es uno de los únicos momentos en los que el estado de datos del ledger se modifica sin una [transacción](../transactions/index.md) o [pseudo-transacción](../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md).
|
||||
**Nota:** Esto es uno de los únicos momentos en los que el estado de datos del ledger se modifica sin una [transacción](../transactions/index.md) o [pseudo-transacción](../../references/protocol/transactions/pseudo-transaction-types/index.md).
|
||||
|
||||
2. Si la UNL negativa no está llena, cada servidor propone añadir **hasta 1** validador a la UNL negativa entre sus validadores confiables con una fiabilidad inferior al 50%.
|
||||
3. Si la UNL negativa no está vacía, cada servidor propone eliminar **hasta 1** validador de la UNL negativa. Un servidor puede proponer eliminar un validador de la UNL negativa por dos motivos:
|
||||
@@ -82,7 +82,7 @@ En cada flag ledger, se aplican todos los siguientes cambios:
|
||||
- No tiene a ese validador en su UNL. (Si un validador deja de funcionar permanentemente, esta regla garantiza que se elimine de la UNL negativa en el ledger después de que se haya eliminado de las UNL configuradas de los servidores).
|
||||
4. Si un cambio propuesto a la UNL negativa logra un consenso, el cambio se programa para entrar en vigencia en el siguiente flag ledger. Se puede programar hasta una adición y una eliminación de esta manera.
|
||||
|
||||
Las propuestas para agregar y eliminar validadores de la UNL negativa toman la forma de [pseudo-transacciones de UNLModify][]. El proceso de consenso determina si cada pseudo-transacción logra un consenso o se descarta, de la misma manera que otras [pseudo-transacciones](../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md). En otras palabras, para que un validador en particular se agregue o elimine a la UNL negativa, se debe lograr un consenso de servidores sobre el mismo cambio.
|
||||
Las propuestas para agregar y eliminar validadores de la UNL negativa toman la forma de [pseudo-transacciones de UNLModify][]. El proceso de consenso determina si cada pseudo-transacción logra un consenso o se descarta, de la misma manera que otras [pseudo-transacciones](../../references/protocol/transactions/pseudo-transaction-types/index.md). En otras palabras, para que un validador en particular se agregue o elimine a la UNL negativa, se debe lograr un consenso de servidores sobre el mismo cambio.
|
||||
|
||||
Los cambios programados y efectivos de la UNL negativa se rastrean en el [objeto NegativeUNL](../../references/protocol/ledger-data/ledger-entry-types/negativeunl.md) en los datos de estado del ledger.
|
||||
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
## {% $frontmatter.seo.title %} フィールド
|
||||
|
||||
[共通フィールド][../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md]に加えて、{% $frontmatter.seo.title %}擬似トランザクションは以下のフィールドを使用します。
|
||||
[共通フィールド][../references/protocol/transactions/pseudo-transaction-types/index.md]に加えて、{% $frontmatter.seo.title %}擬似トランザクションは以下のフィールドを使用します。
|
||||
|
||||
@@ -73,7 +73,7 @@ V<sub>a</sub>は、サーバ側のコンセンサス見解と一致した過去2
|
||||
|
||||
1. 前のフラグレジャーで予定されていたネガティブUNLの変更は、次のレジャーバージョンから有効となる。このフラグレジャーの検証のための合意プロセスそのものは、予定されていた変更を利用しない。
|
||||
|
||||
{% admonition type="info" name="注記" %}これは、[トランザクション](../transactions/index.md)や[疑似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md)を行わずにレジャーの状態データを変更する唯一の機会です。{% /admonition %}
|
||||
{% admonition type="info" name="注記" %}これは、[トランザクション](../transactions/index.md)や[疑似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/index.md)を行わずにレジャーの状態データを変更する唯一の機会です。{% /admonition %}
|
||||
|
||||
2. ネガティブUNLが満杯でない場合、各サーバは信頼度50%未満のバリデータの中から、**最大1つ**のバリデータをネガティブUNLに追加することを提案する。
|
||||
3. ネガティブUNLが空でない場合、各サーバはネガティブUNLから**最大1つ**のバリデータを削除することを提案する。サーバがバリデータをネガティブUNLから削除することを提案できる理由は2つある。
|
||||
@@ -81,7 +81,7 @@ V<sub>a</sub>は、サーバ側のコンセンサス見解と一致した過去2
|
||||
- 自身のUNLにそのバリデータを持たない。(バリデータが永久に停止した場合、このルールは、サーバの設定済みUNLからバリデータが削除された後に、オンレジャーのネガティブUNLからバリデータが削除されることを確実にする)。
|
||||
4. ネガティブUNLの変更案がコンセンサスに達した場合、その変更は次のフラグレジャーから適用される予定である。この方法で最大1つの追加と1つの削除をスケジュールすることができる。
|
||||
|
||||
ネガティブUNLにバリデータを追加したり削除したりする提案は[UNLModify pseudo-transactions][]の形式を取る。それぞれの擬似トランザクションは他の[擬似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md)と同じように合意形成プロセスによって合意を得るか捨てられるかが決定される。言い換えると、あるバリデータがネガティブUNLに追加されたり削除されたりするためには、サーバの総意として同じ変更を提案する必要がある。
|
||||
ネガティブUNLにバリデータを追加したり削除したりする提案は[UNLModify pseudo-transactions][]の形式を取る。それぞれの擬似トランザクションは他の[擬似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/index.md)と同じように合意形成プロセスによって合意を得るか捨てられるかが決定される。言い換えると、あるバリデータがネガティブUNLに追加されたり削除されたりするためには、サーバの総意として同じ変更を提案する必要がある。
|
||||
|
||||
ネガティブUNLの予定された有効な変更は、レジャーの状態データの中の[ネガティブUNLオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/negativeunl.md)に追跡される。
|
||||
|
||||
|
||||
@@ -92,7 +92,7 @@ XRP Ledgerは共有システムとなっていて、すべてのデータが公
|
||||
|
||||
ほとんどのメタデータは、[`AffectedNodes`配列](../../../references/protocol/transactions/metadata.md#affectednodes)に含まれています。この配列で探す対象は、トランザクションのタイプによって異なります。ほぼすべてのトランザクションが、送金元の[AccountRootオブジェクト][]を変更してXRP[トランザクションコスト](../transaction-cost.md)を消却し、[アカウントのシーケンス番号](../../../references/protocol/data-types/basic-data-types.md#アカウントシーケンス)を増やします。
|
||||
|
||||
**情報:** このルールの例外として[疑似トランザクション](../../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md)があります。このトランザクションは実在するアカウントから送信されないため、AccountRootオブジェクトを変更しません。その他の例外として、AccountRootオブジェクトの`Balance`フィールドを変更せずに、AccountRootオブジェクトを変更するトランザクションがあります。[Free Key Resetトランザクション](../transaction-cost.md#key-resetトランザクション)の場合、送金元のXRP残高は変わりません。トランザクションによって消却される金額と同額のXRPをアカウントが受け取る場合（ただし、このようなことはほとんどありません）、そのアカウントの正味残高は変わりません。（XRPを受領したアカウントに関係なくトランザクションコストはメタデータの別の場所に反映されます。）
|
||||
**情報:** このルールの例外として[疑似トランザクション](../../../references/protocol/transactions/pseudo-transaction-types/index.md)があります。このトランザクションは実在するアカウントから送信されないため、AccountRootオブジェクトを変更しません。その他の例外として、AccountRootオブジェクトの`Balance`フィールドを変更せずに、AccountRootオブジェクトを変更するトランザクションがあります。[Free Key Resetトランザクション](../transaction-cost.md#key-resetトランザクション)の場合、送金元のXRP残高は変わりません。トランザクションによって消却される金額と同額のXRPをアカウントが受け取る場合（ただし、このようなことはほとんどありません）、そのアカウントの正味残高は変わりません。（XRPを受領したアカウントに関係なくトランザクションコストはメタデータの別の場所に反映されます。）
|
||||
|
||||
以下は、上記のステップ1からのレスポンス全文例です。レジャーに対して行われた変更を把握できるか確認してください。
|
||||
|
||||
@@ -435,7 +435,7 @@ TrustSetトランザクションは、[`RippleState`オブジェクト](../../..
|
||||
|
||||
### 疑似トランザクション
|
||||
|
||||
[疑似トランザクション](../../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md)にもメタデータがありますが、これらのトランザクションは通常のトランザクションのすべてのルールに従うとは限りません。これらのトランザクションは、実在のアカウントには関連付けられていないため（この`Account`の値は、[base58エンコード形式の数字の0](../../accounts/addresses.md#特別なアドレス)です）、レジャーのAccountRootオブジェクトを変更して`Sequence`シーケンス番号を増やしたり、XRPを消却したりしません。疑似トランザクションは、特別なレジャーオブジェクトに対して特定の変更のみを行います。
|
||||
[疑似トランザクション](../../../references/protocol/transactions/pseudo-transaction-types/index.md)にもメタデータがありますが、これらのトランザクションは通常のトランザクションのすべてのルールに従うとは限りません。これらのトランザクションは、実在のアカウントには関連付けられていないため（この`Account`の値は、[base58エンコード形式の数字の0](../../accounts/addresses.md#特別なアドレス)です）、レジャーのAccountRootオブジェクトを変更して`Sequence`シーケンス番号を増やしたり、XRPを消却したりしません。疑似トランザクションは、特別なレジャーオブジェクトに対して特定の変更のみを行います。
|
||||
|
||||
- [EnableAmendment疑似トランザクション][]は、[Amendmentレジャーオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/amendments.md)を変更して、有効なAmendment、過半数の支持を得ている保留中のAmendment、および保留中の期間を追跡します。
|
||||
- [SetFee疑似トランザクション][]は、[FeeSettingsレジャーオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/feesettings.md)を変更して、[トランザクションコスト](../transaction-cost.md)および[必要準備金](../../accounts/reserves.md)のベースレベルを変更します。
|
||||
|
||||
@@ -9,7 +9,7 @@ labels:
|
||||
---
|
||||
# トランザクション
|
||||
|
||||
_トランザクション（取引）_ は、XRP Ledgerを変更する唯一の方法です。[コンセンサスプロセス](../consensus-protocol/index.md)に従って署名され、送信され、検証済みのレジャーバージョンに承認された場合にのみ、トランザクションは最終的なものになります。レジャーのルールによっては、_[疑似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md)_ も生成されます。このトランザクションは署名も送信もされませんが、コンセンサスによって承認されなければならないことは同様です。失敗したトランザクションであっても、スパム対策の[トランザクションコスト][]を支払のためXRPの残高が変わるため、レジャーに記録されます。
|
||||
_トランザクション（取引）_ は、XRP Ledgerを変更する唯一の方法です。[コンセンサスプロセス](../consensus-protocol/index.md)に従って署名され、送信され、検証済みのレジャーバージョンに承認された場合にのみ、トランザクションは最終的なものになります。レジャーのルールによっては、_[疑似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/index.md)_ も生成されます。このトランザクションは署名も送信もされませんが、コンセンサスによって承認されなければならないことは同様です。失敗したトランザクションであっても、スパム対策の[トランザクションコスト][]を支払のためXRPの残高が変わるため、レジャーに記録されます。
|
||||
|
||||
トランザクションで行えることは、送金だけではありません。XRP Ledgerのトランザクションは、さまざまな[支払いタイプ](../payment-types/index.md)に対応しているだけでなく、[暗号鍵](../accounts/cryptographic-keys.md)のローテーション、その他の設定の管理、およびXRP Ledgerの[分散型取引所](../tokens/decentralized-exchange/index.md)での取引にも使用されます。[トランザクションタイプの詳細なリスト](../../references/protocol/transactions/types/index.md)については、[`rippled` APIリファレンス](../../references/http-websocket-apis/index.md)をご覧ください。
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ metadata:
|
||||
---
|
||||
# トランザクションリファレンス
|
||||
|
||||
_トランザクション_ は、XRP Ledgerを変更する唯一の方法です。[コンセンサスプロセス](../../../concepts/consensus-protocol/index.md)に従って署名され、送信され、検証済みのレジャーバージョンに承認された場合にのみ、トランザクションは[最終](../../../concepts/transactions/finality-of-results/index.md)的なものになります。レジャーのルールによっては、 _[疑似トランザクション](pseudo-transaction-types/pseudo-transaction-types.md)_ も生成されます。このトランザクションは署名も送信もされませんが、コンセンサスによって承認されなければならないことは同様です。失敗したトランザクションも、スパム対策の[トランザクションコスト][]を支払うためにXRPの残高が変更されることから、レジャーに含まれます。
|
||||
_トランザクション_ は、XRP Ledgerを変更する唯一の方法です。[コンセンサスプロセス](../../../concepts/consensus-protocol/index.md)に従って署名され、送信され、検証済みのレジャーバージョンに承認された場合にのみ、トランザクションは[最終](../../../concepts/transactions/finality-of-results/index.md)的なものになります。レジャーのルールによっては、 _[疑似トランザクション](pseudo-transaction-types/index.md)_ も生成されます。このトランザクションは署名も送信もされませんが、コンセンサスによって承認されなければならないことは同様です。失敗したトランザクションも、スパム対策の[トランザクションコスト][]を支払うためにXRPの残高が変更されることから、レジャーに含まれます。
|
||||
|
||||
{% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}
|
||||
|
||||
|
||||
@@ -1,14 +1,12 @@
|
||||
---
|
||||
html: enableamendment.html
|
||||
parent: pseudo-transaction-types.html
|
||||
seo:
|
||||
description: トランザクション処理を変更するAmendmentプロセスの進行状況を追跡します。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
- ブロックチェーン
|
||||
---
|
||||
# EnableAmendment
|
||||
|
||||
トランザクション処理を変更する[Amendmentプロセス](../../../../concepts/networks-and-servers/amendments.md#amendmentプロセス)の進行状況を追跡します。この疑似トランザクションは、提案されたAmendmentが多数の承認を獲得したか否かや、Amendmentの有効化の状況を示します。
|
||||
`EnableAmendment`[疑似トランザクション](./index.md)はトランザクション処理を変更する[Amendmentプロセス](../../../../concepts/networks-and-servers/amendments.md#amendmentプロセス)の進行状況を追跡します。この疑似トランザクションは、提案されたAmendmentが多数の承認を獲得したか否かや、Amendmentの有効化の状況を示します。
|
||||
|
||||
{% admonition type="info" name="注記" %}疑似トランザクションは送信できませんが、レジャーの処理時に疑似トランザクションが見つかることがあります。{% /admonition %}
|
||||
|
||||
|
||||
@@ -1,6 +1,4 @@
|
||||
---
|
||||
html: setfee.html
|
||||
parent: pseudo-transaction-types.html
|
||||
seo:
|
||||
description: 手数料投票の結果としてトランザクションコストまたはアカウント準備金の要件が変更されます。
|
||||
labels:
|
||||
@@ -8,7 +6,7 @@ labels:
|
||||
---
|
||||
# SetFee
|
||||
|
||||
[手数料投票](../../../../concepts/consensus-protocol/fee-voting.md)の結果として[トランザクションコスト](../../../../concepts/transactions/transaction-cost.md)または[アカウント準備金](../../../../concepts/accounts/reserves.md)の要件が変更されます。
|
||||
`SetFee`[疑似トランザクション](./index.md)は[手数料投票](../../../../concepts/consensus-protocol/fee-voting.md)の結果として[トランザクションコスト](../../../../concepts/transactions/transaction-cost.md)または[アカウント準備金](../../../../concepts/accounts/reserves.md)の要件が変更されます。
|
||||
|
||||
{% admonition type="info" name="注記" %}疑似トランザクションは送信できませんが、レジャーの処理時に疑似トランザクションが見つかることがあります。{% /admonition %}
|
||||
|
||||
|
||||
@@ -1,19 +1,17 @@
|
||||
---
|
||||
html: unlmodify.html
|
||||
parent: pseudo-transaction-types.html
|
||||
seo:
|
||||
description: 現在オフラインとみなされている信頼できるバリデータのリストを変更します。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
- ブロックチェーン
|
||||
---
|
||||
# UNLModify
|
||||
|
||||
{% amendment-disclaimer name="NegativeUNL" /%}
|
||||
|
||||
`UNLModify`[疑似トランザクション](pseudo-transaction-types.md)は[Negative UNL](../../../../concepts/consensus-protocol/negative-unl.md)の変更を示し、信頼できるバリデータがオフラインになったかオンラインに戻ってきたことを示します。
|
||||
`UNLModify`[疑似トランザクション](./index.md)は[Negative UNL](../../../../concepts/consensus-protocol/negative-unl.md)の変更を示し、信頼できるバリデータがオフラインになったかオンラインに戻ってきたことを示します。
|
||||
|
||||
{% admonition type="info" name="注記" %}擬似トランザクションを送信することはできませんが、台帳を処理する際に擬似トランザクションを発見することがあります。{% /admonition %}
|
||||
|
||||
{% amendment-disclaimer name="NegativeUNL" /%}
|
||||
|
||||
## {% $frontmatter.seo.title %} JSONの例
|
||||
|
||||
```json
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
## {% $frontmatter.seo.title %} Fields
|
||||
|
||||
In addition to the [common fields](../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md), {% $frontmatter.seo.title %} pseudo-transactions use the following fields:
|
||||
In addition to the [common fields](../references/protocol/transactions/pseudo-transaction-types/index.md), {% $frontmatter.seo.title %} pseudo-transactions use the following fields:
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -92,7 +92,7 @@ Transaction metadata describes _exactly_ how the transaction was applied to the
|
||||
|
||||
Most of the metadata is contained in [the `AffectedNodes` array](../../../references/protocol/transactions/metadata.md#affectednodes). What to look for in this array depends on the type of transaction. Almost every transaction modifies the sender's [AccountRoot object][] to destroy the XRP [transaction cost](../transaction-cost.md) and increase the [account's Sequence number](../../../references/protocol/data-types/basic-data-types.md#account-sequence).
|
||||
|
||||
**Info:** One exception to this rule is for [pseudo-transactions](../../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md), which aren't sent from a real account and thus do not modify an AccountRoot object. There are other exceptions that modify an AccountRoot object without changing its `Balance` field: [free key reset transactions](../transaction-cost.md#key-reset-transaction) do not change the sender's XRP balance; and in the unlikely scenario that a transaction causes an account to receive exactly as much XRP as it destroys, the account's Balance shows no net change. (The net decrease in XRP occurs elsewhere in the metadata, debited from wherever the account sent the XRP.)
|
||||
**Info:** One exception to this rule is for [pseudo-transactions](../../../references/protocol/transactions/pseudo-transaction-types/index.md), which aren't sent from a real account and thus do not modify an AccountRoot object. There are other exceptions that modify an AccountRoot object without changing its `Balance` field: [free key reset transactions](../transaction-cost.md#key-reset-transaction) do not change the sender's XRP balance; and in the unlikely scenario that a transaction causes an account to receive exactly as much XRP as it destroys, the account's Balance shows no net change. (The net decrease in XRP occurs elsewhere in the metadata, debited from wherever the account sent the XRP.)
|
||||
|
||||
This example shows the full response from step 1 above. See if you can figure out what changes it made to the ledger:
|
||||
|
||||
@@ -435,7 +435,7 @@ Most other transactions create a specific type of ledger entry and [adjust the s
|
||||
|
||||
### Pseudo-Transactions
|
||||
|
||||
[Pseudo-transactions](../../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md) also have metadata, but they do not follow all the rules of normal transactions. They are not tied to a real account (the `Account` value is the [base58-encoded form of the number 0](../../accounts/addresses.md#special-addresses)), so they do not modify an AccountRoot object in the ledger to increase the `Sequence` number or destroy XRP. Pseudo-transactions only make specific changes to special ledger objects:
|
||||
[Pseudo-transactions](../../../references/protocol/transactions/pseudo-transaction-types/index.md) also have metadata, but they do not follow all the rules of normal transactions. They are not tied to a real account (the `Account` value is the [base58-encoded form of the number 0](../../accounts/addresses.md#special-addresses)), so they do not modify an AccountRoot object in the ledger to increase the `Sequence` number or destroy XRP. Pseudo-transactions only make specific changes to special ledger objects:
|
||||
|
||||
- [EnableAmendment pseudo-transactions][] modify the [Amendments ledger object](../../../references/protocol/ledger-data/ledger-entry-types/amendments.md) to track which amendments are enabled, and which ones are pending with majority support and for how long.
|
||||
- [SetFee pseudo-transactions][] modify the [FeeSettings ledger object](../../../references/protocol/ledger-data/ledger-entry-types/feesettings.md) to change the base levels for the [transaction cost](../transaction-cost.md) and [reserve requirements](../../accounts/reserves.md).
|
||||
|
||||
@@ -9,7 +9,7 @@ labels:
|
||||
---
|
||||
# Transactions
|
||||
|
||||
A _Transaction_ is the only way to modify the XRP Ledger. Transactions are only final if signed, submitted, and accepted into a validated ledger version following the [consensus process](../consensus-protocol/index.md). Some ledger rules also generate _[pseudo-transactions](../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md)_, which aren't signed or submitted, but still must be accepted by consensus. Transactions that fail are also included in ledgers because they modify balances of XRP to pay for the anti-spam [transaction cost][].
|
||||
A _Transaction_ is the only way to modify the XRP Ledger. Transactions are only final if signed, submitted, and accepted into a validated ledger version following the [consensus process](../consensus-protocol/index.md). Some ledger rules also generate _[pseudo-transactions](../../references/protocol/transactions/pseudo-transaction-types/index.md)_, which aren't signed or submitted, but still must be accepted by consensus. Transactions that fail are also included in ledgers because they modify balances of XRP to pay for the anti-spam [transaction cost][].
|
||||
|
||||
Transactions can do more than send money. In addition to supporting various [Payment Types](../payment-types/index.md), transactions in the XRP Ledger are also used to rotate [cryptographic keys](../accounts/cryptographic-keys.md), manage other settings, and trade in the XRP Ledger's [decentralized exchange](../tokens/decentralized-exchange/index.md). The [`rippled` API reference](../../references/http-websocket-apis/index.md) has a complete [list of transaction types](../../references/protocol/transactions/types/index.md).
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ labels:
|
||||
|
||||
(Not to be confused with the ["ledger hash" string data type][Hash], which uniquely identifies a ledger version. This page describes the `LedgerHashes` ledger entry type.)
|
||||
|
||||
The `LedgerHashes` ledger entry type contains a history of prior ledgers that led up to this ledger version, in the form of their hashes. Entries of this type are modified automatically when closing a ledger. (This is one of the only times a ledger's state data is modified without a [transaction](../../../../concepts/transactions/index.md) or [pseudo-transaction](../../transactions/pseudo-transaction-types/pseudo-transaction-types.md).) The `LedgerHashes` entries 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` ledger entry type contains a history of prior ledgers that led up to this ledger version, in the form of their hashes. Entries of this type are modified automatically when closing a ledger. (This is one of the only times a ledger's state data is modified without a [transaction](../../../../concepts/transactions/index.md) or [pseudo-transaction](../../transactions/pseudo-transaction-types/index.md).) The `LedgerHashes` entries 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` entry. Both types have the same fields. Each ledger version contains:
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ metadata:
|
||||
---
|
||||
# Transaction Reference
|
||||
|
||||
A _Transaction_ is the only way to cause changes in the XRP Ledger. Transactions' outcomes are only [final](../../../concepts/transactions/finality-of-results/index.md) if signed, submitted, and accepted into a validated ledger version following the [consensus process](../../../concepts/consensus-protocol/index.md). Some ledger rules also generate _[pseudo-transactions](pseudo-transaction-types/pseudo-transaction-types.md)_, which aren't signed or submitted, but still must be accepted by consensus. Transactions that fail are also included in ledgers because they modify balances of XRP to pay for the anti-spam [transaction cost][].
|
||||
A _Transaction_ is the only way to cause changes in the XRP Ledger. Transactions' outcomes are only [final](../../../concepts/transactions/finality-of-results/index.md) if signed, submitted, and accepted into a validated ledger version following the [consensus process](../../../concepts/consensus-protocol/index.md). Some ledger rules also generate _[pseudo-transactions](pseudo-transaction-types/index.md)_, which aren't signed or submitted, but still must be accepted by consensus. Transactions that fail are also included in ledgers because they modify balances of XRP to pay for the anti-spam [transaction cost][].
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
|
||||
@@ -2,12 +2,12 @@
|
||||
seo:
|
||||
description: Enable a change in transaction processing.
|
||||
labels:
|
||||
- Blockchain
|
||||
- Blockchain
|
||||
---
|
||||
# EnableAmendment
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/Change.cpp "Source")
|
||||
|
||||
An `EnableAmendment` pseudo-transaction marks a change in the status of a proposed amendment. The possible status changes are:
|
||||
An `EnableAmendment` [pseudo-transaction](./index.md) marks a change in the status of a proposed [amendment to the protocol](../../../../concepts/networks-and-servers/amendments.md). The possible status changes are:
|
||||
|
||||
- The amendment gains supermajority approval from validators.
|
||||
- The amendment loses supermajority approval.
|
||||
@@ -34,7 +34,7 @@ An `EnableAmendment` pseudo-transaction marks a change in the status of a propos
|
||||
|
||||
| Field | JSON Type | [Internal Type][] | Description |
|
||||
|:-----------------|:----------|:------------------|:--------------------------|
|
||||
| `Amendment` | String | UInt256 | A unique identifier for the amendment. This is not intended to be a human-readable name. See [Amendments](../../../../concepts/networks-and-servers/amendments.md) for a list of known amendments. |
|
||||
| `Amendment` | String | UInt256 | A unique identifier for the amendment. This is not intended to be a human-readable name. See [Known Amendments](../../../../../resources/known-amendments.md) for a list of known amendments. |
|
||||
| `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
|
||||
|
||||
@@ -2,12 +2,12 @@
|
||||
seo:
|
||||
description: Change global reserve and transaction cost settings.
|
||||
labels:
|
||||
- Fees
|
||||
- Fees
|
||||
---
|
||||
# SetFee
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/Change.cpp "Source")
|
||||
|
||||
A `SetFee` [pseudo-transaction](pseudo-transaction-types.md) marks a change in [transaction cost](../../../../concepts/transactions/transaction-cost.md) or [reserve requirements](../../../../concepts/accounts/reserves.md) as a result of [Fee Voting](../../../../concepts/consensus-protocol/fee-voting.md).
|
||||
A `SetFee` [pseudo-transaction](./index.md) marks a change in [transaction cost](../../../../concepts/transactions/transaction-cost.md) or [reserve requirements](../../../../concepts/accounts/reserves.md) as a result of [fee voting](../../../../concepts/consensus-protocol/fee-voting.md).
|
||||
|
||||
{% admonition type="info" name="Note" %}You cannot send a pseudo-transaction, but you may find one when processing ledgers.{% /admonition %}
|
||||
|
||||
@@ -58,7 +58,7 @@ This transaction has two formats, depending on whether the [XRPFees amendment][]
|
||||
|
||||
## {% $frontmatter.seo.title %} Fields
|
||||
|
||||
The fields of a SetFee pseudo-transaction depend on whether the [XRPFees amendment][] was enabled at the time. In addition to the [common fields](./pseudo-transaction-types.md), they can use the following:
|
||||
The fields of a SetFee pseudo-transaction depend on whether the [XRPFees amendment][] was enabled at the time. In addition to the [common fields](./index.md), they can use the following:
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="Current Format" %}
|
||||
|
||||
@@ -1,20 +1,18 @@
|
||||
---
|
||||
html: unlmodify.html
|
||||
parent: pseudo-transaction-types.html
|
||||
seo:
|
||||
description: Change the list of trusted validators currently considered offline.
|
||||
labels:
|
||||
- Blockchain
|
||||
- Blockchain
|
||||
---
|
||||
# UNLModify
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/Change.cpp "Source")
|
||||
|
||||
{% amendment-disclaimer name="NegativeUNL" /%}
|
||||
|
||||
A `UNLModify` [pseudo-transaction](pseudo-transaction-types.md) marks a change to the [Negative UNL](../../../../concepts/consensus-protocol/negative-unl.md), indicating that a trusted validator has gone offline or come back online.
|
||||
A `UNLModify` [pseudo-transaction](./index.md) marks a change to the [Negative UNL](../../../../concepts/consensus-protocol/negative-unl.md), indicating that a trusted validator has gone offline or come back online.
|
||||
|
||||
{% admonition type="info" name="Note" %}You cannot send a pseudo-transaction, but you may find one when processing ledgers.{% /admonition %}
|
||||
|
||||
{% amendment-disclaimer name="NegativeUNL" /%}
|
||||
|
||||
## Example {% $frontmatter.seo.title %} JSON
|
||||
|
||||
```json
|
||||
@@ -31,7 +29,6 @@ A `UNLModify` [pseudo-transaction](pseudo-transaction-types.md) marks a change t
|
||||
```
|
||||
|
||||
{% partial file="/docs/_snippets/pseudo-tx-fields-intro.md" /%}
|
||||
<!--{# fix md highlighting_ #}-->
|
||||
|
||||
| Name | JSON Type | [Internal Type][] | Description |
|
||||
|:---------------------|:----------|:------------------|:----------------------|
|
||||
|
||||
@@ -1,3 +1,6 @@
|
||||
/docs/references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types/:
|
||||
to: /docs/references/protocol/transactions/pseudo-transaction-types/
|
||||
type: 301
|
||||
/docs/concepts/tokens/transfer-fees/:
|
||||
to: /docs/concepts/tokens/fungible-tokens/transfer-fees/
|
||||
type: 301
|
||||
|
||||
@@ -447,7 +447,7 @@
|
||||
- page: docs/references/protocol/transactions/types/xchaincreatebridge.md
|
||||
- page: docs/references/protocol/transactions/types/xchaincreateclaimid.md
|
||||
- page: docs/references/protocol/transactions/types/xchainmodifybridge.md
|
||||
- page: docs/references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md
|
||||
- page: docs/references/protocol/transactions/pseudo-transaction-types/index.md
|
||||
expanded: false
|
||||
items:
|
||||
- page: docs/references/protocol/transactions/pseudo-transaction-types/enableamendment.md
|
||||
|
||||
Reference in New Issue
Block a user