Use UD60x18 in the Dynamic contract

[andreivladbrg]

While I was making the change from uint256 to uint128 for the totalAmount and withdrawnAmount variables,
it dawned on me that the only reason we use SD59x18 in the SablierV2LockupDynamic contract is to allow a negative exponent.

IMO it is unnecessary to use SD59x18 because it complicates things with the all conversions we have to make.

Given that we use the pow function only here:

https://github.com/sablierhq/v2-core/blob/8bd57ebb31fddf6ef262477e5a378027db8b85d8/src/SablierV2LockupDynamic.sol#L338

Where: $elapsedTimePercentage \in R+ , \forall currentSegmentExponent => multiplier \ge 0$

My proposal is to either add a function in our contract either add in the PRBMath library called powi for the UD60x18 type.

/// @param x The base as an UD60x18 number.
/// @param y The exponent as an int256.
/// @return result The result as an UD60x18 number.
function powi(UD60x18 x, int256 y) external returns (UD60x18 result);

This may also solve this issue #178.

[PaulRBerg]

This is a great idea. I agree that this would be useful, but to keep concerns separated, we should implement this in PRBMath, rather than here.

Here's a draft spec:

/// @dev If y < 0, do `inv(pow(x, ud(-y)))`
/// If y >= 0, do `pow(x, ud(y))`
/// @param x The base as an UD60x18 number.
/// @param y The exponent as an SD59x18 number.
/// @return result The result as an UD60x18 number.
function pow(UD60x18 x, SD59x18 y) external returns (UD60x18 result);

Let's try to see if the compiler works with pow first .. if not, set it as powi and I will find a better name later.

[andreivladbrg]

Why would you use SD59x18 for the exponent? The whole idea is to not use SD59x18. It will require to import both of them in the Dynamic contract.

[PaulRBerg]

Shoot, you are right .. but the problem with not using SD59x18 for the y argument is that this violates one of the core assumptions of PRBMath (especially V3), which is that all non-value-typed arguments are non-fixed-point.

In your initial design, you were planning on using y as a fixed-point type but give it the vanilla type int256.

Maybe this should be implemented in v2-core .. in some Helpers library or something like that.

[andreivladbrg]

Found out that there is another reason for using SD59x18.

Using UD60x18 would force us to have only whole numbers for the base in the pow functions, which is imposible for our case, elapsedTimePercentage is a percentage <= 1e18.

Even so, I still think that would be a good idea to change the exponent type to int64, the maximum value that fits in is: 9_223372036854775807. So we would not need a MAX_EXPONENT constant anymore.

[PaulRBerg]

I think that you meant to say "have only super-unitary number" instead of "whole number", i.e. numbers greater than or equal to 1e18.

What you're saying about int64 is an interesting idea, but I'm a bit skeptical.

• We would have to write a function that converts int64 to SD59x18 (which will cost gas, so we would have to do a benchmark to see if there is any gas saved)
• The API would be a bit counter-intuitive to someone who is familiar with PRBMath

Could you open a separate discussion to track this idea?

[PaulRBerg]

@andreivladbrg do you still want to pursue this idea, or do you concur that we can't use UD60x18?

There is a check in the UD60x18 log2 function that checks if the input is at least 1 (the binary logarithm of any number lower than 1 is negative).

[andreivladbrg]

@andreivladbrg do you still want to pursue this idea, or do you concur that we can't use UD60x18?

No, I don't

There is a check in the UD60x18 log2 function that checks if the input is at least 1 (the binary logarithm of any number lower than 1 is negative).

Yes, we can't use UD60x18 in the Dynamic contract

[PaulRBerg]

Great, thanks for confirming.