Change internal math reference precision from 1e9 to 1e27 to make the PositiveTokenRebaseLimiter library more robust against unusual input data
Context:
As a part of the Repovation initiative the PositiveTokenRebase library (contracts/0.8.9/lib/PositiveTokenRebaseLimiter.sol) has been covered with an extensive fuzzing test suite.
What:
Turns out the internal math precision with a reference 1 == 1e9 is insufficient to maintain wide (or even unconstrainted) data boundaries, see the relevant code in https://github.com/lidofinance/core/pull/88, the method is testFuzz_getSharesToBurnLimit. When the values are out of range, the allowed theoretical positive rebase start diverging from the calculated one due to the weak precision math.
It should be possible to maintain the accuracy for the following assumptions:
allow near zero protocol TVL not sacrificing on the estimation precision (the current model uses 1 ether, better to allow 1 gwei at least)
require more accuracy for max rebase calculation (the current model requires 0.1 basis point, wish it was 0.001 basis point)
allow more outrageous share rates for the model (0.001 ≤ shareRate ≤ 1000 ⇒ 1e-6 ≤ shareRate ≤ 1e6)
allow more drastically changes for decreaseEther to be passed
Possible fix:
Implement getSharesToBurnLimit with the internal 1e27 precision model.
tl;dr
Change internal math reference precision from
1e9to1e27to make thePositiveTokenRebaseLimiterlibrary more robust against unusual input dataContext:
As a part of the Repovation initiative the
PositiveTokenRebaselibrary (contracts/0.8.9/lib/PositiveTokenRebaseLimiter.sol) has been covered with an extensive fuzzing test suite.What:
Turns out the internal math precision with a reference
1 == 1e9is insufficient to maintain wide (or even unconstrainted) data boundaries, see the relevant code in https://github.com/lidofinance/core/pull/88, the method istestFuzz_getSharesToBurnLimit. When the values are out of range, the allowed theoretical positive rebase start diverging from the calculated one due to the weak precision math.It should be possible to maintain the accuracy for the following assumptions:
1 ether, better to allow1 gweiat least)0.1 basis point, wish it was0.001 basis point)0.001 ≤ shareRate ≤ 1000⇒1e-6 ≤ shareRate ≤ 1e6)decreaseEtherto be passedPossible fix:
Implement
getSharesToBurnLimitwith the internal1e27precision model.