mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-05 20:35:50 +00:00
fee voting - fix and/or error
This commit is contained in:
@@ -12,7 +12,7 @@ Operators of [`rippled` validators](rippled-setup.html#running-a-validator) can
|
||||
|
||||
### Voting Process ###
|
||||
|
||||
Every 256th ledger is called a "flag" ledger. (A flag ledger is defined such that the `ledger_index` [modulo](https://en.wikipedia.org/wiki/Modulo_operation) `256` is equal to `0`.) In the ledger immediately before the flag ledger, each validator whose account reserve and transaction cost preferences are different than the current network setting distributes a "vote" message alongside its ledger validation, indicating the values that validator prefers.
|
||||
Every 256th ledger is called a "flag" ledger. (A flag ledger is defined such that the `ledger_index` [modulo](https://en.wikipedia.org/wiki/Modulo_operation) `256` is equal to `0`.) In the ledger immediately before the flag ledger, each validator whose account reserve or transaction cost preferences are different than the current network setting distributes a "vote" message alongside its ledger validation, indicating the values that validator prefers.
|
||||
|
||||
In the flag ledger itself, nothing happens, but validators receive and take note of the votes from other validators they trust.
|
||||
|
||||
|
||||
@@ -168,7 +168,7 @@
|
||||
</tbody>
|
||||
</table>
|
||||
<h3 id="voting-process">Voting Process</h3>
|
||||
<p>Every 256th ledger is called a "flag" ledger. (A flag ledger is defined such that the <code>ledger_index</code> <a href="https://en.wikipedia.org/wiki/Modulo_operation">modulo</a> <code>256</code> is equal to <code>0</code>.) In the ledger immediately before the flag ledger, each validator whose account reserve and transaction cost preferences are different than the current network setting distributes a "vote" message alongside its ledger validation, indicating the values that validator prefers.</p>
|
||||
<p>Every 256th ledger is called a "flag" ledger. (A flag ledger is defined such that the <code>ledger_index</code> <a href="https://en.wikipedia.org/wiki/Modulo_operation">modulo</a> <code>256</code> is equal to <code>0</code>.) In the ledger immediately before the flag ledger, each validator whose account reserve or transaction cost preferences are different than the current network setting distributes a "vote" message alongside its ledger validation, indicating the values that validator prefers.</p>
|
||||
<p>In the flag ledger itself, nothing happens, but validators receive and take note of the votes from other validators they trust. </p>
|
||||
<p>After counting the votes of other validators, each validator attempts to compromise between its own preferences and the preferences of a majority of validators it trusts. (For example, if one validator wants to raise the minimum transaction cost from 10 to 100, but most validators only want to raise it from 10 to 20, the one validator settles on the change to raise the cost to 20. However, the one validator never settles on a value lower than 10 or higher than 100.) If a compromise is possible, the validator inserts a <a href="transactions.html#setfee">SetFee pseudo-transaction</a> into its proposal for the ledger following the flag ledger. Other validators who want the same change insert an identical SetFee pseudo-transaction into their proposals for the same ledger. (Validators whose preferences match the existing network settings do nothing. Validators also do nothing if their preferences are the opposite of the preferences from a majority of validators they trust.) If a SetFee psuedo-transaction survives the consensus process to be included in a validated ledger, then the new transaction cost and reserve settings denoted by the SetFee pseudo-transaction takes effect starting with the following ledger.</p>
|
||||
<p>In short:</p>
|
||||
|
||||
Reference in New Issue
Block a user