Fix default gas price and rounding issues

[trusch]

No description provided.

[trusch]

I'm wondering if I should try to get rid of floating point operations all together. I don't like that there are cases for high gas where it would blow up. The thing is, a user wants to specify ucredit/gas, and this is 0.025 in our case. I could represent this as how many gas you get for one ucredit, i.e. 40 gas/ucredit. Then we could just use integer operations.

The current code works, but I really don't like seeing f64 in a computation about credits. It helps that we only have 6 decimals and not 18, but still.

[tuommaki]

I'm wondering if I should try to get rid of floating point operations all together. I don't like that there are cases for high gas where it would blow up. The thing is, a user wants to specify ucredit/gas, and this is 0.025 in our case. I could represent this as how many gas you get for one ucredit, i.e. 40 gas/ucredit. Then we could just use integer operations.

The current code works, but I really don't like seeing f64 in a computation about credits. It helps that we only have 6 decimals and not 18, but still.

I'd propose two alternatives:

1. Make the UX to work with credits but parse them literally as ucredits and then perform all calculations with integers (not sure if u128 is enough or if you need some kind of big ints here; at least remember to use checked operations to watch out for overflows).
2. Make the UX specifically to work with ucredits and then try to document it the best in the CLI help.

Would either of those options work? I agree with you that floating point calculation in this context is not the best, although the small rounding error is still bearable.

[trusch]

@tuommaki this doesnt work unfortunately because we need less than one ucredit for one gas. Its 0.025 ucredit/gas. Currently (before this PR) the whole UX was in ucredits, but this only allows to specify a minimal gas price of 1 ucredit/gas which is still 40 times higher than what we want.

[miax-gevu]

I'm wondering if I should try to get rid of floating point operations all together.

IMO, yes

[trusch]

Ok, let me try something :)

[tuommaki]

@tuommaki this doesnt work unfortunately because we need less than one ucredit for one gas. Its 0.025 ucredit/gas. Currently (before this PR) the whole UX was in ucredits, but this only allows to specify a minimal gas price of 1 ucredit/gas which is still 40 times higher than what we want.

Uhm, but there is no way to deal with fractional ucredits on-chain, or is there?

[trusch]

@tuommaki No, not on-chain. The whole logic is part of the node logic, not the actual state transition. The node logic also introduces this rounding error, this is why using ceil() in this PR fixes it. The node also multiplies the floating point with the gas that is needed to calculate how many token it wants.

You can also see that this calculation is not part of the state transition because it is configurable on a per-node basis and not part of the genesis or anything else.

[tuommaki]

@tuommaki No, not on-chain. The whole logic is part of the node logic, not the actual state transition. The node logic also introduces this rounding error, this is why using ceil() in this PR fixes it. The node also multiplies the floating point with the gas that is needed to calculate how many token it wants.

You can also see that this calculation is not part of the state transition because it is configurable on a per-node basis and not part of the genesis or anything else.

Ah, right, but in this case I recon you then need to multiply the "precision" with 10^3 to account for fractional gas price in integers?

I'd maybe go with floats right now to fix the most pressing issue and then implement a separate Rust module to encapsulate these calculations w/ tests?