SIMD-0194: Deprecate rent exemption threshold #194
Conversation
Minor edits / suggestions
| Set the value of `DEFAULT_EXEMPTION_THRESHOLD` from `2.0` to `1.0`, and | ||
| deprecate it from the protocol. |
There was a problem hiding this comment.
How do you propose deprecation? I'm curious which one hurts less post-deprecation: changing to 1u64 and preserving the account layout/size, or complete removal, changing the account size.
There was a problem hiding this comment.
We simply stop using it in any SDKs and thus any new programs going forward will be using u64 math, simply omitting the f64 value entirely, but it will remain in the rent account to not break the existing API and will be flagged as deprecated.
| * Allow users to make the assumption that `2.0` will remain stable and do `u64` | ||
| math themselves. |
There was a problem hiding this comment.
We could stablize this, but imo the field will soon become a misnomer, considering rent collection is being disabled. I think your proposed design makes more sense.
Fix lint
…deprecate-rent-exemption-threshold.md
deanmlittle
changed the title
There was a problem hiding this comment.
The whole concept of Rent is going away. Since no accounts are rent-paying currently, the rent lamports can be considered a state bond. A big goal with state economics is to enable this state bond to be dynamic and reduce 100x or so. Under normal load this drops "rent" to be much much cheaper, while also allowing higher loads to exponentially increase fees to allocate state.
I think we'd want new sysvars/etc for programs to be able to read, so this change to the exemption threshold is probably fine.
| the `lamports_per_byte` value. Any existing program using the current | ||
| implementation will be unaffected. | ||
|
|
||
| ## Alternatives Considered |
There was a problem hiding this comment.
Seems like another alternative is to check if the bitpattern of exemption_threshold is 2.0 (bitwise comparison, not floating point), and then if true, do the math as described in this PR above.
Kinda hacky, I agree.
There was a problem hiding this comment.
Moving forward, we can actually skip the equivalence check entirely if we just decide that the best outcome for this SIMD is to ossify it at 2.0. The thing is, if we're already going to do that, it feels much cleaner to change it to 1.0 so it can be mathematically simplified out of the fee calculation formula as opposed to just being ignored.
No description provided.