Sabitlenmiş Tweet
Three weeks ago KyberSwap was hacked for $50M due to a rounding error vulnerability 💸💸💸
This is a bug class that is often overlooked or misunderstood by developers and auditors, so I’ve created the following mini-course to explain how to correctly handle rounding, using @trailofbits new tool roundme.
Time commitment: ~60 minutes
--------
First, watch this ~30m video by @0xOwenThurm that gives a great overview of this class of bugs:
youtube.com/watch?v=6rmLP-…
Next, to illustrate a rounding error in an actual contract, let’s imagine that we’re building a simple xy=k AMM for swapping two ERC-20 tokens; token x and token y. To accentuate the potential impact of a rounding error, let’s assume these tokens both have 0 decimals, so we can deal with small integers where rounding errors are the most unforgiving.
From the constant product equation xy=k, we can derive the equation for how many of token y a user will receive for swapping a given amount of token x:
Where:
x ⇒ Amount of token x reserves in the AMM
y ⇒ Amount of token y reserves in the AMM
xIn ⇒ Amount of token x the user is swapping
yOut ⇒ Amount of token y user will receive
So in our AMM smart contract we'll write the function calcSwapXForY which implements the above equation. We’ll also utilize a helper function mulDivDown, which multiplies two numbers and divides by a third number, and rounds down.
Let's assume the AMM currently holds 10 of token x, 8 of token y, and the user is swapping 5 of token x for token y, so we call calcSwapXForY with the following values:
xReserves = 10
yReserves = 8
xIn = 5
We get the result:
yOut = 3
However, if we were to do this same calculation outside the context of the EVM, without any integer rounding or precision loss, we would get the result: yOut = 2.66667
So due to the rounding precision loss, the user is receiving 12.5% more tokens than they nominally should be. This hypothetical AMM could clearly be exploited.
This is where roundme can be helpful for determining whether we should round up or down at each relevant operation in the equation. Let’s get it setup.
Clone the roundme repo and follow the installation procedure in the readme:
github.com/crytic/roundme
Now in the terminal we can run:
roundme config
Next roundme asks for the formula to analyze, so we input our equation:
yReserves - ((xReserves * yReserves) / (xReserves + xIn))
Roundme then asks if we would like the output of the equation to round up. We want yOut to round down, so the user receives fewer tokens, favoring the protocol instead of the user. So we input:
no
This generates our config.yaml file:
We can now run:
roundme analyze
And we receive the analysis
(yreserves - ((xreserves *↑ yreserves) /↑ (xreserves + xin)))
Roundme has added two arrows to our formula that indicate the direction that operation should be rounded.
The first up arrow is next to our multiplication operation, but since we aren’t doing fixed point arithmetic, this multiplication won’t cause any precision loss and we can ignore it.
The second up arrow is next to our division operation, which does result in precision loss, so we want to pay attention to this one.
So we want our division to round up, for our final result yOut to round down. That’s a key takeaway from this course:
✍️
If the result of the entire equation should round in a certain direction, that doesn’t necessarily mean intermediate operations within the equation should round in that same direction.
In this case, since we are subtracting our rounded amount from yReserves, this flips 🔄the required rounding direction.
The roundme repo does a good job of explaining the affect different math operations have on overall rounding direction:
--------
rounding() is the expected rounding direction for the result (up or down)
A + B => rounding(A), rounding(B) (addition does not change the rounding direction)
A - B => rounding(A), ! rounding(B) (the rounding direction of the subtracted element is inverse of the expected rounding)
A * B => rounding(A), rounding(B), rounding(*) (multiplication does not change the rounding direction)
A / B => rounding(A), ! rounding(B), rounding(/) (the rounding direction of the denominator is the inverse of the expected rounding)
--------
Let’s rewrite our swapping function, with our newfound knowledge that we should round up on our division. We are using a helper function mulDivUp, that multiplies two numbers, and divides by a third number, and rounds up.
Let's call safeCalcSwapXForY with the same values as before:
xReserves = 10
yReserves = 8
xIn = 5
And we now get the result:
yOut = 2
Now the user is receiving fewer tokens than the nominal (no precision loss) result we calculated earlier. So our new function favors the protocol, not the user, and can’t be exploited!
This was a relatively simple example, and you may have intuitively known we should round up on our division operation. However with much larger equations this intuition will likely fail you, and roundme will prove to be invaluable.
I hope this helps with understanding rounding errors in EVM smart contracts, and sheds some light on this great new tool we have at our disposal.
Special thanks to @Montyly for answering a roundme question I had, and to the rest of ToB for making open source tools to share with the Web3 security community.
Stay tuned for more content like this 🤟
YouTube
English
