-
Notifications
You must be signed in to change notification settings - Fork 65
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #1486 from ipopescu/1475_fee_elimination
1475/1437 - Add fee elimination and update economics concepts
- Loading branch information
Showing
18 changed files
with
502 additions
and
230 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
63 changes: 63 additions & 0 deletions
63
source/docs/casper/concepts/economics/dynamic-gas-pricing.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,63 @@ | ||
| --- | ||
| title: Dynamic Gas Pricing | ||
| --- | ||
|
|
||
| # Dynamic Gas Pricing on Mainnet | ||
|
|
||
| The Condor release introduced a configurable capability to calculate dynamic gas prices based on block vacancy (or consumption). The network chainspec configures the `vacancy`, as shown below, which refers to this feature. This capability prevents malicious actors from filling the blocks with useless transactions and ensures network integrity. | ||
|
|
||
| When dynamic gas pricing is enabled, a calculation runs at the end of each era to average block usage within that era. This calculation determines the gas price the network will use for the next era. If overall consumption rises above a threshold, the gas price increases by 1. If consumption falls below a threshold, the gas price decreases by 1. The gas price remains the same if overall consumption remains within those thresholds. The gas price will not go up or down by more than 1 in a given era and will not go above the maximum or below the minimum threshold. | ||
|
|
||
| The gas price is recorded in the block header and is easily discoverable for current and historical purposes. The current gas price is a multiplier that determines the actual gas cost. For instance, an operation with a base cost of 1 CSPR would cost 1 CSPR if the current gas price is 1 but would cost 2 CSPR if the current gas price is 2. As blocks become congested, the amount of CSPR required to obtain a slot for executing transactions will increase by a multiple. The following configuration settings control this behavior: | ||
|
|
||
| - `upper_threshold` - The threshold to decrease gas price | ||
| - `lower_threshold` - The threshold to increase gas price | ||
| - `max_gas_price` - The maximum gas price | ||
| - `min_gas_price` - The minimum gas price | ||
|
|
||
|
|
||
| ### Mainnet Condor Configurations | ||
|
|
||
| These are the block vacancy (dynamic gas pricing) settings for the Condor release on Mainnet. Before Condor, the gas price was 1, meaning 1 unit of gas cost 1 mote. With Condor, the multiple is configured to adjust between 1 and 3. | ||
|
|
||
| <!--TODO check and update these settings after the launch or link to the chainspec file directly.--> | ||
|
|
||
| ```toml | ||
| [vacancy] | ||
| # The cost of a transaction is based on a multiplier. This allows for economic disincentives for misuse of the network. | ||
| # | ||
| # The network starts with a current_gas_price of min_gas_price. | ||
| # | ||
| # Each block has multiple limits (bytes, transactions, transfers, gas, etc.) | ||
| # The utilization for a block is determined by the highest percentage utilization of each these limits. | ||
| # | ||
| # Ex: transfers limit is 650 and transactions limit is 20 (assume other limits are not a factor here) | ||
| # 19 transactons -> 19/20 or 95% | ||
| # 600 transfers -> 600/650 or 92.3% | ||
| # resulting block utilization is 95 | ||
| # | ||
| # The utilization for an era is the average of all block utilizations. At the switch block, the dynamic gas_price is | ||
| # adjusted with the following: | ||
| # | ||
| # If utilization was below the lower_threshold, current_gas_price is decremented by one if higher than min_gas_price. | ||
| # If utilization falls between the thresholds, current_gas_price is not changed. | ||
| # If utilization was above the upper_threshold, current_gas_price is incremented by one if lower than max_gas_price. | ||
| # | ||
| # The cost charged for the transaction is simply the gas_used * current_gas_price. | ||
| upper_threshold = 90 | ||
| lower_threshold = 50 | ||
| max_gas_price = 3 | ||
| min_gas_price = 1 | ||
| ``` | ||
|
|
||
| ## Fixed Transaction Costs vs. Dynamic Gas Prices | ||
|
|
||
| The current gas price and the slot’s maximum gas cost determine how much CSPR gets locked up for a transaction. Thus, the transaction price is predictable and fixed but has a dynamic component in that it’s pegged to the gas price. The system is designed this way to protect the network, adjusting the gas price as needed. Read more about lanes and gas cost [here](./runtime.md#lanes-and-gas-costs-lanes). Also, the `pricing_handling = { type = 'fixed' }` setting is described [here](./fee-elimination.md). | ||
|
|
||
| ## Gas Tolerance | ||
|
|
||
| :::caution | ||
| The cost of interacting with the blockchain increases during high network usage. Plan accordingly for any transactions and use the gas_tolerance field described below. | ||
| ::: | ||
|
|
||
| Transactions have a `gas_tolerance` field, allowing the sender to specify the maximum gas price they are willing to pay (the minimum is 1). For instance, if a transaction is sent with `gas_tolerance = 2` and the network is currently at a gas price of 3 or higher, that transaction will not be included in a proposed block. If the calculated gas price decreases to 2 before the transaction has expired, the transaction will be eligible for inclusion in a proposed block. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,93 @@ | ||
| --- | ||
| title: Fee Elimination | ||
| --- | ||
|
|
||
| # Fee Elimination on Mainnet | ||
|
|
||
| Casper networks support configurable fee, refund, and pricing strategies. The Mainnet Condor release has enabled "fee elimination", also known as the "no fee mode", or "no fee transactions" to reduce operational costs for developers. This configurable feature places balance holds on a user's purse rather than taking fees for sending transactions to the network. This behavior benefits parties who send periodic transactions, as their gas costs are locked for some time and then either released all at once or linearly over time, depending on the chainspec settings. Recall that the network chainspec contains all the configuration choices on which every node must agree. | ||
|
|
||
| Instead of paying for gas to execute transactions, the `no_fee` chainspec configuration instructs the network to place a balance hold on the paying purse without transferring tokens from the purse: `fee_handling = { type = 'no_fee'}`. The portion of a purse balance that is locked is not available to transfer or spend until it is released; it is marked with a timestamp equal to the block time. In the "no fee" mode, the available balance of a purse equals its actual total balance minus all non-expired balance holds on that purse. The configurable `gas_hold_interval` determines how long a balance hold remains in effect. The on-chain logic calculates the correct values for total balance and available balance. The [query_balance_details](../../developers/json-rpc/json-rpc-informational.md#query_balance_details) RPC endpoint provides details on available balances and hold records. | ||
|
|
||
| :::note | ||
|
|
||
| A processing hold is not the same as a gas (or balance) hold. The processing hold is a temporary hold that prevents double spend. For example, if you want to do a transfer, you also need to cover the cost of the transfer. | ||
|
|
||
| ::: | ||
|
|
||
| ## Chainspec Configurations | ||
|
|
||
| The following [chainspec configurations](../../operators/setup-network/chain-spec.md) manage this feature: | ||
|
|
||
| - `fee_handling` - Defines how fees are handled. To enable the "no fee" mode, set it to `{ type = 'no_fee'}`. | ||
| - `refund_handling` Defines how refunds of the unused portion of payment amounts are calculated and handled. For this setting to work with the "no fee" mode, set it to `{ type = 'no_refund'}`. If no fees are transferred from the paying purse, no refunds need to be paid out. | ||
| - `pricing_handling` - Defines how pricing is handled. For this setting to work with the `no_fee` mode, set it to `{ type = 'fixed'}`, which means that costs are fixed per the cost table, and senders do not specify how much they pay. | ||
| - `validator_credit_cap` - The validator credit cannot exceed this percentage of their total stake. | ||
| - `gas_hold_balance_handling - Defines how gas holds affect available balance calculations. Valid options are 'accrued' (the sum of the full value of all non-expired holds) and 'amortized' (the sum of each hold is amortized over the time remaining until expiry). | ||
| - `gas_hold_interval` - Defines how long gas holds last. | ||
|
|
||
| ### Mainnet Condor Configurations | ||
|
|
||
| These are the fee elimination settings for the Condor release on Mainnet: | ||
| <!--TODO check and update these settings after the launch or link to the chainspec file directly.--> | ||
|
|
||
| ```toml | ||
| # Defines how refunds of the unused portion of payment amounts are calculated and handled. | ||
| # | ||
| # Valid options are: | ||
| # 'refund': a ratio of the unspent token is returned to the spender. | ||
| # 'burn': a ratio of the unspent token is burned. | ||
| # 'no_refund': no refunds are paid out; this is functionally equivalent to refund with 0% ratio. | ||
| # This causes excess payment amounts to be sent to either a | ||
| # pre-defined purse, or back to the sender. The refunded amount is calculated as the given ratio of the payment amount | ||
| # minus the execution costs. | ||
| refund_handling = { type = 'no_refund' } | ||
| # Defines how fees are handled. | ||
| # | ||
| # Valid options are: | ||
| # 'no_fee': fees are eliminated. | ||
| # 'pay_to_proposer': fees are paid to the block proposer | ||
| # 'accumulate': fees are accumulated in a special purse and distributed at the end of each era evenly among all | ||
| # administrator accounts | ||
| # 'burn': fees are burned | ||
| fee_handling = { type = 'no_fee' } | ||
| # If a validator would recieve a validator credit, it cannot exceed this percentage of their total stake. | ||
| validator_credit_cap = [1, 5] | ||
| # Defines how pricing is handled. | ||
| # | ||
| # Valid options are: | ||
| # 'classic': senders of transaction self-specify how much they pay. | ||
| # 'fixed': costs are fixed, per the cost table | ||
| # 'reserved': prepaid transaction (currently not supported) | ||
| pricing_handling = { type = 'fixed' } | ||
|
|
||
| # Defines how gas holds affect available balance calculations. | ||
| # | ||
| # Valid options are: | ||
| # 'accrued': sum of full value of all non-expired holds. | ||
| # 'amortized': sum of each hold is amortized over the time remaining until expiry. | ||
| # | ||
| # For instance, if 12 hours remained on a gas hold with a 24-hour `gas_hold_interval`, | ||
| # with accrued, the full hold amount would be applied | ||
| # with amortized, half the hold amount would be applied | ||
| gas_hold_balance_handling = { type = 'accrued' } | ||
| # Defines how long gas holds last. | ||
| # | ||
| # If fee_handling is set to 'no_fee', the system places a balance hold on the payer | ||
| # equal to the value the fee would have been. Such balance holds expire after a time | ||
| # interval has elapsed. This setting controls how long that interval is. The available | ||
| # balance of a purse equals its total balance minus the held amount(s) of non-expired | ||
| # holds (see gas_hold_balance_handling setting for details of how that is calculated). | ||
| # | ||
| # For instance, if gas_hold_interval is 24 hours and 100 gas is used from a purse, | ||
| # a hold for 100 is placed on that purse and is considered when calculating total balance | ||
| # for 24 hours starting from the block_time when the hold was placed. | ||
| gas_hold_interval = '24 hours' | ||
| ``` | ||
|
|
||
| ## Computational and Storage Costs | ||
|
|
||
| Despite the introduction of fee elimination, the network continues to track [computational cost](../design/casper-design.md#measuring-computational-work-execution-semantics-gas) based on opcodes as defined in the chainspec, thus retaining the [gas pricing mechanism](./gas-concepts.md). Opcodes enable Casper nodes to agree on the computational cost of transactions, commonly known as gas. This mechanism is a solution to the halting problem in a distributed network, and it abstracts the computational cost in a way that is deterministically consistent across multiple machines. | ||
|
|
||
| Storage costs are also tracked and calculated using gas. Data written to global state is recorded forever and has a cost; therefore, the network charges for the Wasm that stores data in global state. | ||
|
|
||
| This feature complements the [dynamic gas pricing](./dynamic-gas-pricing.md) model introduced and configured to scale gas costs based on network utilization. |
Oops, something went wrong.