mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-12-06 17:27:57 +00:00
tx cost - FeeEscalation changes (in progress)
This commit is contained in:
@@ -139,8 +139,23 @@
|
|||||||
<p>You can also <a href="#querying-the-transaction-cost">query <code>rippled</code> for the current transaction cost</a>.</p>
|
<p>You can also <a href="#querying-the-transaction-cost">query <code>rippled</code> for the current transaction cost</a>.</p>
|
||||||
<h2 id="beneficiaries-of-the-transaction-cost">Beneficiaries of the Transaction Cost</h2>
|
<h2 id="beneficiaries-of-the-transaction-cost">Beneficiaries of the Transaction Cost</h2>
|
||||||
<p>The transaction cost is not paid to any party: the XRP is irrevocably destroyed. Since no new XRP can ever be created, this makes XRP more scarce, and consequently benefits all holders of XRP by making XRP more valuable.</p>
|
<p>The transaction cost is not paid to any party: the XRP is irrevocably destroyed. Since no new XRP can ever be created, this makes XRP more scarce, and consequently benefits all holders of XRP by making XRP more valuable.</p>
|
||||||
<h2 id="load-scaling">Load Scaling</h2>
|
<h2 id="load-cost-and-open-ledger-cost">Load Cost and Open Ledger Cost</h2>
|
||||||
<p>Each <code>rippled</code> server independently scales the transaction cost 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 cost meets the overall minimum.) 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>
|
<p>When the <a href="concept-amendments.html#feeescalation">FeeEscalation amendment</a> is enabled, there are two thresholds for the transaction cost:</p>
|
||||||
|
<ul>
|
||||||
|
<li>If the transaction cost does not meet a <code>rippled</code> server's load-based transaction cost threshold, the server ignores the transaction completely. (This logic is essentially unchanged with or without the amendment.)</li>
|
||||||
|
<li>If the transaction cost does not meet a <code>rippled</code> server's Open Ledger cost threshold, the queues the transaction for the next ledger.</li>
|
||||||
|
</ul>
|
||||||
|
<p>This divides transactions into roughly three categories:</p>
|
||||||
|
<ul>
|
||||||
|
<li>Transactions that specify a transaction cost so low that they get rejected by the load-based transaction cost.</li>
|
||||||
|
<li>Transactions that specify a transaction cost high enough to be included in the current open ledger.</li>
|
||||||
|
<li>Transactions in between, which get queued for the next open ledger.</li>
|
||||||
|
</ul>
|
||||||
|
<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 cost meets the overall minimum.) 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>A <code>rippled</code> server with the <a href="concept-amendments.html#feeescalation">FeeEscalation amendment</a> enabled has a second mechanism for enforcing the transaction cost, called the <em>open ledger cost</em>. The open ledger cost increases exponentially when an in-progress ledger has more transactions than the previous one, so that only transactions which pay more than the normal transaction cost can be included in the current open ledger.</p>
|
||||||
|
<p>The open ledger cost requirement is proportional to the normal cost of the transaction, 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>
|
||||||
<h2 id="querying-the-transaction-cost">Querying the Transaction Cost</h2>
|
<h2 id="querying-the-transaction-cost">Querying the Transaction Cost</h2>
|
||||||
<p>The <code>rippled</code> APIs have two ways to query the transaction cost: the <code>server_info</code> command (intended for humans) and the <code>server_state</code> command (intended for machines).</p>
|
<p>The <code>rippled</code> APIs have two ways to query the transaction cost: the <code>server_info</code> command (intended for humans) and the <code>server_state</code> command (intended for machines).</p>
|
||||||
<h3 id="server-info">server_info</h3>
|
<h3 id="server-info">server_info</h3>
|
||||||
|
|||||||
@@ -17,9 +17,29 @@ You can also [query `rippled` for the current transaction cost](#querying-the-tr
|
|||||||
The transaction cost is not paid to any party: the XRP is irrevocably destroyed. Since no new XRP can ever be created, this makes XRP more scarce, and consequently benefits all holders of XRP by making XRP more valuable.
|
The transaction cost is not paid to any party: the XRP is irrevocably destroyed. Since no new XRP can ever be created, this makes XRP more scarce, and consequently benefits all holders of XRP by making XRP more valuable.
|
||||||
|
|
||||||
|
|
||||||
## Load Scaling ##
|
## Load Cost and Open Ledger Cost ##
|
||||||
|
|
||||||
Each `rippled` server independently scales the transaction cost based on its current load. If you submit a transaction with a `Fee` value that is lower than current load-based transaction cost of the `rippled` server, that server neither applies nor relays the transaction. (**Note:** If you submit a transaction through an [admin connection](reference-rippled.html#connecting-to-rippled), the server applies and relays the transaction as long as the transaction cost meets the overall minimum.) A transaction is very unlikely to survive [the consensus process](https://ripple.com/knowledge_center/the-ripple-ledger-consensus-process/) unless its `Fee` value meets the requirements of a majority of servers.
|
When the [FeeEscalation amendment](concept-amendments.html#feeescalation) is enabled, there are two thresholds for the transaction cost:
|
||||||
|
|
||||||
|
* If the transaction cost does not meet a `rippled` server's load-based transaction cost threshold, the server ignores the transaction completely. (This logic is essentially unchanged with or without the amendment.)
|
||||||
|
* If the transaction cost does not meet a `rippled` server's Open Ledger cost threshold, the queues the transaction for the next ledger.
|
||||||
|
|
||||||
|
This divides transactions into roughly three categories:
|
||||||
|
|
||||||
|
* Transactions that specify a transaction cost so low that they get rejected by the load-based transaction cost.
|
||||||
|
* Transactions that specify a transaction cost high enough to be included in the current open ledger.
|
||||||
|
* Transactions in between, which get queued for the next open ledger.
|
||||||
|
|
||||||
|
|
||||||
|
## Local Load Cost ##
|
||||||
|
|
||||||
|
Each `rippled` server maintains a cost threshold based on its current load. If you submit a transaction with a `Fee` value that is lower than current load-based transaction cost of the `rippled` server, that server neither applies nor relays the transaction. (**Note:** If you submit a transaction through an [admin connection](reference-rippled.html#connecting-to-rippled), the server applies and relays the transaction as long as the transaction cost meets the overall minimum.) A transaction is very unlikely to survive [the consensus process](https://ripple.com/knowledge_center/the-ripple-ledger-consensus-process/) unless its `Fee` value meets the requirements of a majority of servers.
|
||||||
|
|
||||||
|
## Open Ledger Cost ##
|
||||||
|
|
||||||
|
A `rippled` server with the [FeeEscalation amendment](concept-amendments.html#feeescalation) enabled has a second mechanism for enforcing the transaction cost, called the _open ledger cost_. The open ledger cost increases exponentially when an in-progress ledger has more transactions than the previous one, so that only transactions which pay more than the normal transaction cost can be included in the current open ledger.
|
||||||
|
|
||||||
|
The open ledger cost requirement is proportional to the normal cost of the transaction, not the absolute transaction cost. Transaction types that have a higher-than-normal requirement, such as [multi-signed transactions](reference-transaction-format.html#multi-signing) must pay more to meet the open ledger cost than transactions which have minimum transaction cost requirements.
|
||||||
|
|
||||||
|
|
||||||
## Querying the Transaction Cost ##
|
## Querying the Transaction Cost ##
|
||||||
|
|||||||
Reference in New Issue
Block a user