CEP 89: Fee elimination #89
Conversation
|
@MParlikar, please review at your convenience |
| @@ -0,0 +1,83 @@ | |||
| # Elimination of gas fees | |||
|
|
|||
There was a problem hiding this comment.
"Review" to point out parts of this CEP to be reworked
|
|
||
| CEP PR: [casperlabs/ceps#0089](https://github.com/casperlabs/ceps/pull/89) | ||
|
|
||
| We propose introduction of a delayed gas fee refund feature, replacing the (currently inactive) refund feature. |
There was a problem hiding this comment.
The summary should describe this CEP as reflecting code already in the release candidate codebase and the CEP should do the following
- Change all terminology to reflect the rough consensus between external written material (the fee elimination impact documents) and naming conventions within the codebase itself
- Introduce clear definitions with above consensus terminology as basis, upfront
- Introduce the concepts of lane configuration and different pricing modes
- Concomitantly make a clear delineation between recommended chainspec settings for mainnet and the alternatives enabled by interaction of various parameters
- Introduce our light "theoretical" analysis of the behavior of a no-fee system under attack and direct the readers to review the fee elimination impact document
- Potentially separate the validator credit feature into a separate CEP, depending on complexity of this CEP after initial revisions
|
|
||
| [motivation]: #motivation | ||
|
|
||
| Due to the inherent uncertainty in gas costs caused by variation in inputs, users almost always need to overclaim gas to eliminate risk of reversion. Because as-implemented instant refunds are currently set to 0, this creates a serious UX problem, as users must almost always overpay to guarantee successful execution. Unfortunately, given the execution-after-consensus paradigm Casper uses, meaningful non-zero refunds create a serious attack vector, enabling malicious or careless users to fill up blocks with overclaimed gas. |
There was a problem hiding this comment.
This section works conceptually but needs to separate UX concerns about refunds with the refund feature, which still very much exists and could be enabled. Additionally, partial refunds have been activated at some point on mainnet, I believe.
The section must also include the description of the utility of fee elimination for BaaS providers
|
|
||
| To address both the UX issue and the security issue with refunds, we propose a re-implementation of the refund feature, introducing delayed refunds with a percentage of "used" token made available to the user on a linear schedule. Unlike the current refund feature, the new system will functionally refund all token and not just token paid for overclaimed gas. | ||
|
|
||
| Note that we use the term "refund" for simplicity and to emphasize the viewpoint of the user. However, token "spent" under the new system will not be transferred or otherwise associated with any account other than that of the user. |
There was a problem hiding this comment.
Replace "refund" as used here with "hold/release" terminology
|
|
||
| ### Changes to gas fee logic | ||
|
|
||
| No changes, at least due to the introduction of this feature, are expected to be made to the calculation of gas fees. |
There was a problem hiding this comment.
Replace terminology here and elsewhere "gas fees" -> "gas costs"
|
|
||
| [drawbacks]: #drawbacks | ||
|
|
||
| Elimination of user fees paid to validators creates adverse incentives for validators. In the interest of keeping |
There was a problem hiding this comment.
This needs to be broken out into a separate CEP now that we have the validator credit feature, potentially
|
|
||
| [prior-art]: #prior-art | ||
|
|
||
| We do not currently know of an example of another blockchain replacing the use of token as transferable payment for computation with the use of token as permanent claim to some portion of the blockchain's compute. |
There was a problem hiding this comment.
Do another round of competitive analysis here to confirm
Rendered