sdk: Refactor Rentsysvar

[febo]

Problem

The concept of rent no longer exists, only rent-exemption, and upstream BPF does not support f64 values but currently the Rent sysvar implementation uses them.

Solution

Refactor the sysvar implementation and remove all references to f64.

[joncinque]

Just one question about the target_os = solana part, the rest looks great!

[joncinque]

Looks great! Just the bit about saturating math, but we can address later

[joncinque]

I know this code has been here for some time, but I'm just realizing that we now have an opportunity to overflow this calculation, which wasn't the case when it used floats. Should we eventually use some saturating math here to be safe?

[febo]

This is a tricky one. Adding saturated math increased CUs by ~70, which is about 50%. It will probably be cheaper to validate the data_len and lamports_per_byte values so that we can determine that it won't overflow.

[joncinque]

Wow, I didn't think it would be so bad! Adding checks makes sense to me, and if it's costly, we could only check data_len and add a warning specifying the range of valid values for lamports_per_byte

[febo]

Adding a test on both data_len and lamports_per_byte takes 6 extra CUs. The caveat is that currently minimum_exempt is not a fallible function, so either we would need to panic or change the return type.

We could probably have a minimum_exempt and an unsafe minimim_exempt_unchecked (without the validation).

[joncinque]

That makes sense to me -- performance is getting huge gains anyway from not using floats, so the extra checks are not such a big deal

[febo]

Added a fallible try_minimum_balance and unsafe minimum_balance_unchecked; also deprecated the minimum_balance, which now would panic if data_len exceeds the maximum allowed.

It is a bit tricky to have a good check for lamports_per_byte, since it depends on both exempt_threshold and maximum data_len. I was thinking that we can assume that the runtime guarantees the value of lamports_per_byte is valid in relation to the maximum data_len.

[joncinque]

Should we just store this as a u64 to make things simpler?

[febo]

We can everything as a [u8; 8] if we use an if statements instead of a match – no difference in CUs (eb6d8da).

[joncinque]

Ah interesting, good to know! Do we know if that's a problem with codegen? It seems like the two should be equivalent, no?

[febo]

I checked this and the compiler/llvm won't be able to infer all the information to optimize when used in a match statement, so this is the expected behaviour.