mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-16 01:35:50 +00:00
rippled 0.32.0, trustsetauth changes for peer review
This commit is contained in:
mDuo13
@@ -339,7 +339,7 @@ TrustSetAuth
|
||||
</tbody>
|
||||
</table>
|
||||
<p>Allows pre-authorization of accounting relationships (zero-balance trust lines) when using <a href="tutorial-gateway-guide.html#authorized-accounts">Authorized Accounts</a>.</p>
|
||||
<p>With this amendment enabled, a <code>TrustSet</code> transaction with <a href="reference-transaction-format.html#trustset-flags"><code>tfSetfAuth</code> enabled</a> can create a new <a href="reference-ledger-format.html#ripplestate"><code>RippleState</code> ledger node</a> even if it keeps all the other values of the <code>RippleState</code> node in their default state. The new <code>RippleState</code> node has the <a href="reference-ledger-format.html#ripplestate-flags"><code>lsfLowAuth</code> or <code>lsfHighAuth</code> flag</a> enabled appropriately. The sender of the transaction must have <a href="reference-ledger-format.html#accountroot-flags"><code>lsfRequireAuth</code> enabled</a>.</p>
|
||||
<p>With this amendment enabled, a <code>TrustSet</code> transaction with <a href="reference-transaction-format.html#trustset-flags"><code>tfSetfAuth</code> enabled</a> can create a new <a href="reference-ledger-format.html#ripplestate"><code>RippleState</code> ledger node</a> even if it keeps all the other values of the <code>RippleState</code> node in their default state. The new <code>RippleState</code> node has the <a href="reference-ledger-format.html#ripplestate-flags"><code>lsfLowAuth</code> or <code>lsfHighAuth</code> flag</a> enabled, depending on whether the sender of the transaction is considered the low node or the high node. The sender of the transaction must have already enabled <a href="reference-ledger-format.html#accountroot-flags"><code>lsfRequireAuth</code></a> by sending an <a href="reference-transaction-format.html#accountset">AccountSet transaction</a> with the <a href="reference-transaction-format.html#accountset-flags">asfRequireAuth flag enabled</a>.</p>
|
||||
<h2 id="tickets">Tickets</h2>
|
||||
<table>
|
||||
<thead>
|
||||
|
||||
@@ -215,7 +215,7 @@
|
||||
<h2 id="local-load-cost">Local Load Cost</h2>
|
||||
<p>Each <code>rippled</code> server maintains a cost threshold based on its current load. If you submit a transaction with a <code>Fee</code> value that is lower than current load-based transaction cost of the <code>rippled</code> server, that server neither applies nor relays the transaction. (<strong>Note:</strong> If you submit a transaction through an <a href="reference-rippled.html#connecting-to-rippled">admin connection</a>, the server applies and relays the transaction as long as the transaction meets the un-scaled minimum transaction cost.) A transaction is very unlikely to survive <a href="https://ripple.com/knowledge_center/the-ripple-ledger-consensus-process/">the consensus process</a> unless its <code>Fee</code> value meets the requirements of a majority of servers.</p>
|
||||
<h2 id="open-ledger-cost">Open Ledger Cost</h2>
|
||||
<p>The <code>rippled</code> server has a second mechanism for enforcing the transaction cost, called the <em>open ledger cost</em>. A transaction can only be included in the open ledger if it meets the open ledger cost requirement in XRP. Transactions that do not meet the open ledger cost are <a href="#queued-transactions">queued for a following ledger</a> instead.</p>
|
||||
<p>The <code>rippled</code> server has a second mechanism for enforcing the transaction cost, called the <em>open ledger cost</em>. A transaction can only be included in the open ledger if it meets the open ledger cost requirement in XRP. Transactions that do not meet the open ledger cost may be <a href="#queued-transactions">queued for a following ledger</a> instead.</p>
|
||||
<p>For each new ledger version, the server picks a soft limit on the number of transactions to be included in the open ledger, based on the number of transactions in the previous ledger. The open ledger cost is equal to the minimum un-scaled transaction cost until the number of transactions in the open ledger is equal to the soft limit. After that, the open ledger cost increases exponentially for each transaction included in the open ledger. For the next ledger, the server increases the soft limit if the current ledger contained more transactions than the soft limit, and decreases the soft limit if the consensus process takes more than 5 seconds.</p>
|
||||
<p>The open ledger cost requirement is <a href="#fee-levels">proportional to the normal cost of the transaction</a>, not the absolute transaction cost. Transaction types that have a higher-than-normal requirement, such as <a href="reference-transaction-format.html#multi-signing">multi-signed transactions</a> must pay more to meet the open ledger cost than transactions which have minimum transaction cost requirements.</p>
|
||||
<p>See also: <a href="https://github.com/ripple/rippled/blob/release/src/ripple/app/misc/FeeEscalation.md">Fee Escalation explanation in <code>rippled</code> repository</a>.</p>
|
||||
@@ -228,7 +228,7 @@
|
||||
<li>Transactions must be properly-formed and <a href="reference-transaction-format.html#authorizing-transactions">authorized</a> with valid signatures.</li>
|
||||
<li>Transactions with an <code>AccountTxnID</code> field cannot be queued.</li>
|
||||
<li>A single sending address can have at most 10 transactions queued at the same time. In order for a transaction to be queued, the sender must have enough XRP to pay all the XRP costs of all the sender's queued transactions including both the <code>Fee</code> fields and the sum of the XRP that each transaction could send. If a transaction affects how the address authorizes accounts, no other transactions from the same address can be queued behind it. <em>(New in <a href="https://github.com/ripple/rippled/releases/tag/0.32.0"><code>rippled</code> 0.32.0</a>)</em></li>
|
||||
<li>If the transaction includes a <code>LastLedgerSequence</code> field, the value of that field must not be more than <strong>the current ledger index + 2</strong>.</li>
|
||||
<li>If the transaction includes a <code>LastLedgerSequence</code> field, the value of that field must be at least <strong>the current ledger index + 2</strong>.</li>
|
||||
</ul>
|
||||
<h2 id="reference-transaction-cost">Reference Transaction Cost</h2>
|
||||
<p>The "Reference Transaction" is the cheapest (non-free) transaction, in terms of the necessary <a href="concept-transaction-cost.html">transaction cost</a> before load scaling. Most transactions have the same cost as the reference transaction. Some transactions, such as <a href="reference-transaction-format.html#multi-signing">multi-signed transactions</a>, require a multiple of this cost instead. When the open ledger cost escalates, the requirement is proportional to the basic cost of the transaction.</p>
|
||||
|
||||
@@ -161,7 +161,7 @@ Provides "Suspended Payments" for XRP for escrow within the Ripple Consensus Led
|
||||
|
||||
Allows pre-authorization of accounting relationships (zero-balance trust lines) when using [Authorized Accounts](tutorial-gateway-guide.html#authorized-accounts).
|
||||
|
||||
With this amendment enabled, a `TrustSet` transaction with [`tfSetfAuth` enabled](reference-transaction-format.html#trustset-flags) can create a new [`RippleState` ledger node](reference-ledger-format.html#ripplestate) even if it keeps all the other values of the `RippleState` node in their default state. The new `RippleState` node has the [`lsfLowAuth` or `lsfHighAuth` flag](reference-ledger-format.html#ripplestate-flags) enabled appropriately. The sender of the transaction must have [`lsfRequireAuth` enabled](reference-ledger-format.html#accountroot-flags).
|
||||
With this amendment enabled, a `TrustSet` transaction with [`tfSetfAuth` enabled](reference-transaction-format.html#trustset-flags) can create a new [`RippleState` ledger node](reference-ledger-format.html#ripplestate) even if it keeps all the other values of the `RippleState` node in their default state. The new `RippleState` node has the [`lsfLowAuth` or `lsfHighAuth` flag](reference-ledger-format.html#ripplestate-flags) enabled, depending on whether the sender of the transaction is considered the low node or the high node. The sender of the transaction must have already enabled [`lsfRequireAuth`](reference-ledger-format.html#accountroot-flags) by sending an [AccountSet transaction](reference-transaction-format.html#accountset) with the [asfRequireAuth flag enabled](reference-transaction-format.html#accountset-flags).
|
||||
|
||||
## Tickets ##
|
||||
|
||||
|
||||
@@ -47,7 +47,7 @@ Each `rippled` server maintains a cost threshold based on its current load. If y
|
||||
|
||||
## Open Ledger Cost ##
|
||||
|
||||
The `rippled` server has a second mechanism for enforcing the transaction cost, called the _open ledger cost_. A transaction can only be included in the open ledger if it meets the open ledger cost requirement in XRP. Transactions that do not meet the open ledger cost are [queued for a following ledger](#queued-transactions) instead.
|
||||
The `rippled` server has a second mechanism for enforcing the transaction cost, called the _open ledger cost_. A transaction can only be included in the open ledger if it meets the open ledger cost requirement in XRP. Transactions that do not meet the open ledger cost may be [queued for a following ledger](#queued-transactions) instead.
|
||||
|
||||
For each new ledger version, the server picks a soft limit on the number of transactions to be included in the open ledger, based on the number of transactions in the previous ledger. The open ledger cost is equal to the minimum un-scaled transaction cost until the number of transactions in the open ledger is equal to the soft limit. After that, the open ledger cost increases exponentially for each transaction included in the open ledger. For the next ledger, the server increases the soft limit if the current ledger contained more transactions than the soft limit, and decreases the soft limit if the consensus process takes more than 5 seconds.
|
||||
|
||||
@@ -68,7 +68,7 @@ The `rippled` server uses a variety of heuristics to estimate which transactions
|
||||
* Transactions must be properly-formed and [authorized](reference-transaction-format.html#authorizing-transactions) with valid signatures.
|
||||
* Transactions with an `AccountTxnID` field cannot be queued.
|
||||
* A single sending address can have at most 10 transactions queued at the same time. In order for a transaction to be queued, the sender must have enough XRP to pay all the XRP costs of all the sender's queued transactions including both the `Fee` fields and the sum of the XRP that each transaction could send. If a transaction affects how the address authorizes accounts, no other transactions from the same address can be queued behind it. _(New in [`rippled` 0.32.0](https://github.com/ripple/rippled/releases/tag/0.32.0))_
|
||||
* If the transaction includes a `LastLedgerSequence` field, the value of that field must not be more than **the current ledger index + 2**.
|
||||
* If the transaction includes a `LastLedgerSequence` field, the value of that field must be at least **the current ledger index + 2**.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -8656,9 +8656,6 @@ The `state` object may have some arrangement of the following fields:
|
||||
| load.threads | Number | *Admin only* The number of threads in the server's main job pool. |
|
||||
| load\_base | Integer | This amount of server load is the baseline that is used to decide how much to charge in transaction fees; if the `load_factor` is equal to the `load_base` then only the base fee is enforced; if the `load_factor` is double the `load_base` then transaction costs are doubled. |
|
||||
| load\_factor | Number | The load factor the server is currently enforcing. The ratio between this value and the `load_base` determines the multiplier for transaction fees. The load factor is determined by the highest of the individual server's load factor, cluster's load factor, and the overall network's load factor. |
|
||||
| load\_factor\_local | Integer | (May be omitted) The load factor based on load to this server. |
|
||||
| load\_factor\_net | Integer | (May be omitted) The load factor being used by the rest of the network (estimated). |
|
||||
| load\_factor\_cluster | Integer | (May be omitted) The load factor based on load to servers in [this cluster](tutorial-rippled-setup.html#clustering). |
|
||||
| load\_factor\_fee\_escalation | Integer | (May be omitted) The current multiplier to the [transaction cost][] that a transaction must pay to get into the open ledger, in fee levels. _(New in [version 0.32.0][])_ |
|
||||
| load\_factor\_fee\_queue | Integer | (May be omitted) The current multiplier to the [transaction cost][] that a transaction must pay to get into the queue, if the queue is full, in fee levels. _(New in [version 0.32.0][])_ |
|
||||
| load\_factor\_fee\_reference | Integer | (May be omitted) The [transaction cost][] with no load scaling, in fee levels. _(New in [version 0.32.0][])_ |
|
||||
|
||||
@@ -1049,7 +1049,7 @@ These codes indicate an error in the local server processing the transaction; it
|
||||
| telBAD\_DOMAIN | The transaction specified a domain value (for example, the `Domain` field of an [AccountSet transaction](#accountset)) that cannot be used, probably because it is too long to store in the ledger. |
|
||||
| telBAD\_PATH_COUNT | The transaction contains too many paths for the local server to process. |
|
||||
| telBAD\_PUBLIC\_KEY | The transaction specified a public key value (for example, as the `MessageKey` field of an [AccountSet transaction](#accountset)) that cannot be used, probably because it is too long. |
|
||||
| telCAN\_NOT\_QUEUE | The transaction did not meet the [open ledger cost](concept-transaction-cost.html), but this server did not queue it because it failed one of the server's heuristics for being "likely to succeed". You can try again later or sign and submit a replacement transaction with a higher transaction cost in the `Fee` field. |
|
||||
| telCAN\_NOT\_QUEUE | The transaction did not meet the [open ledger cost](concept-transaction-cost.html), but this server did not queue this transaction because it did not meet the [queuing restrictions](concept-transaction-cost.html#queuing-restrictions). You can try again later or sign and submit a replacement transaction with a higher transaction cost in the `Fee` field. |
|
||||
| telFAILED\_PROCESSING | An unspecified error occurred when processing the transaction. |
|
||||
| telINSUF\_FEE_P | The `Fee` from the transaction is not high enough to meet the server's current [transaction cost](concept-transaction-cost.html) requirement, which is derived from its load level. |
|
||||
| telLOCAL_ERROR | Unspecified local error. |
|
||||
|
||||
@@ -10233,21 +10233,6 @@ rippled server_state
|
||||
<td>The load factor the server is currently enforcing. The ratio between this value and the <code>load_base</code> determines the multiplier for transaction fees. The load factor is determined by the highest of the individual server's load factor, cluster's load factor, and the overall network's load factor.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>load_factor_local</td>
|
||||
<td>Integer</td>
|
||||
<td>(May be omitted) The load factor based on load to this server.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>load_factor_net</td>
|
||||
<td>Integer</td>
|
||||
<td>(May be omitted) The load factor being used by the rest of the network (estimated).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>load_factor_cluster</td>
|
||||
<td>Integer</td>
|
||||
<td>(May be omitted) The load factor based on load to servers in <a href="tutorial-rippled-setup.html#clustering">this cluster</a>.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>load_factor_fee_escalation</td>
|
||||
<td>Integer</td>
|
||||
<td>(May be omitted) The current multiplier to the <a href="concept-transaction-cost.html">transaction cost</a> that a transaction must pay to get into the open ledger, in fee levels. <em>(New in <a href="https://github.com/ripple/rippled/releases/tag/0.32.0">version 0.32.0</a>)</em></td>
|
||||
|
||||
@@ -1736,7 +1736,7 @@
|
||||
</tr>
|
||||
<tr>
|
||||
<td>telCAN_NOT_QUEUE</td>
|
||||
<td>The transaction did not meet the <a href="concept-transaction-cost.html">open ledger cost</a>, but this server did not queue it because it failed one of the server's heuristics for being "likely to succeed". You can try again later or sign and submit a replacement transaction with a higher transaction cost in the <code>Fee</code> field.</td>
|
||||
<td>The transaction did not meet the <a href="concept-transaction-cost.html">open ledger cost</a>, but this server did not queue this transaction because it did not meet the <a href="concept-transaction-cost.html#queuing-restrictions">queuing restrictions</a>. You can try again later or sign and submit a replacement transaction with a higher transaction cost in the <code>Fee</code> field.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>telFAILED_PROCESSING</td>
|
||||
|
||||
Reference in New Issue
Block a user