Add sqrt for math

[jjz]

Fixes #3149

When we use SWAP, we often need to use the sqrt operation, which is not in Math, so I added it.

https://github.com/Uniswap/v2-core/blob/4dd59067c76dea4a0e8e4bfdda41877a6b16dedc/contracts/UniswapV2Pair.sol#L95

PR Checklist

• Tests
• Documentation
• Changelog entry

[frangio]

Thanks @jjz.

Some things we want to do before merging:

• Measure worst-case gas cost.
• Compare worst-case gas cost with Balancer's LogExpMath.

[jjz]

I don't know what kind of evaluation is needed, because this method is pure

[Amxx]

The version in #3282 is simpler (no special case, but has the drawback of overflowing for sqrt(type(uint256).max)

   function sqrt(uint256 x) public pure returns (uint256 y) {
        uint256 z = (x + 1) / 2; // This can overflow
        y = x;
        while (z < y) {
            y = z;
            z = (x / z + z) / 2;
        }
        return y;
    }

This can be fixed by doing

   function sqrt(uint256 x) public pure returns (uint256 y) {
        uint256 z = x / 2 + x % 2; // This cannot overflow
        y = x;
        while (z < y) {
            y = z;
            z = (x / z + z) / 2;
        }
        return y;
    }

I suggest we use that version.

[Amxx]

Gas costs are worryingly high. Finding the sqrt of type(uint256).max cost about 35k gas

[Amxx]

PRB has a version with constant cost

IMO this would be much better. It's a bit more expensive for small values, but it is orders of magnitude cheaper for big values.

[frangio]

This is only the case for perfect squares, we should document the behavior for the other numbers. I suppose it rounds down.

Does it make sense (is it possible?) to provide a version with a Rounding argument?

Do you think we can document some aspect of the efficiency of this function? It's O(1) but can we say anything stronger in terms of the constants involved?

[Amxx]

Added a version with Rounding

[Amxx]

I guess we could provide an upper bound on the gas cost, I'm not sure what else we can say

[frangio]

I would write this like this, otherwise we basically need to count Fs to know if the code is right.

        if (x > (1 << 128) - 1) {

The compiler seems to optimize this expression to a constant, even when optimizations are disabled.

[Amxx]

then what about doing x >= 1 << 128. Would that also get optimized? to the same bytecode. Because there is no gte opcode I'm worried it would be compiled to not(lt(..., ...))

[Amxx]

I think I found an even better rewording.

[frangio]

I don't think this is clear or accurate.

For our first guess, we use the log2 of the square root.

What does it mean that we "use the log2"? I read this like saying that our guess is log2(sqrt(a)), but I don't think this is true.

I also find the part about shifting a confusing.

[frangio]

Looks good to me.