Precision of invariant() is inconsistent

[robertleifke]

Description:

The invariant function of the Pair.sol contract does not function as intended due to a mismatch in fixed-point precision.
As shown in figure 6.1, the invariant method multiplies and divides values by 1e18 to manage precision. For example, the scale0 and scale1 values are multiplied by 1e18 before dividing by the value of the liquidity variable to maintain a precision of 1e18, the same as that of the function’s input values.

The a, b, and c terms of the core invariant logic increase the precision to 1e36, which is appropriate for arithmetic that is sensitive to rounding errors. The d term, however, uses native exponentiation to raise a value with 1e18 precision to the fourth power, yielding a number with 1e72 precision. The underlying value of the d term is therefore orders of magnitude larger than that of the others, preventing the invariant from being satisfied under expected circumstances (e.g., the arithmetic operations can easily revert due to overflow protection).

Action items:

• Consider a fixed-point power function to raise the upperBound value to the fourth power.
• Alternatively, or in addition, use the FullMath.mulDiv function and native multiplication calls to produce a result with 1e36 precision.
• Measure each option due to different rounding properties, so test all possibilities and choose the one that best fits the requirements of the new invariant.
• Write thorough tests that confirm the solution behaves and rounds as intended.
• Document the precision used for all critical values. This will facilitate a review of the codebase and help prevent similar issues.
• LHS and RHS need to match.
• Sufficient unit and integration tests exist for all components, and use fuzzing tests to check proper behavior at the bounds.