This article was first published on æternity blog - Medium
How lifting limitations of Ethereum prevents hacks by design — hacks that cost ERC20 token owners several millions so far. An example.
The most unexpected events sometimes lead to disastrous consequences. In the design of smart contracts, it hasn’t always taken confusing code structure or sloppy logic to cause major havoc. Sometimes, it takes only something as simple as arithmetic operators from elementary school: Addition, Subtraction and Multiplication.
Taking as examples
2²⁵⁶ — 1
which are the smallest and largest numbers (unsigned integers) that can be represented in the Ethereum Virtual Machine (EVM).
Although they appear to be distant from each other from a numeric point of view, they are, from a developer’s perspective, far too close for comfort: Subtracting 1 from the former number or adding 1 to the latter results to
0–1 == 2²⁵⁶ — 1
2²⁵⁶ — 1 + 1 == 0
An integer overflow occurs — the numbers “wrap around”.
This has remained default behaviour in Ethereum due to limitations of the EVM. Developers are forced to establish extra checks to prevent this from becoming a problem — which hasn’t always gone well, as you will see below.
Why is This so Important?
In 2018 and subsequent years the so called ‘batchOverflow bug’ in many of Ethereum Token Contracts allowed malicious actors to create tokens from thin air, thereby causing major damage to exchanges and token owners.
In a batchOverflow bug exploit, a hacker transfers tokens to multiple recipients — more tokens than the hacker actually owns — by calling the token contract’s transfer function in a seemingly unproblematic way.
To explain how that common exploit is abused and what Aeternity has established to prevent this by design, let’s reimplement the same exploitable problematic contract logic in Sophia, Aeternity’s Smart Contract Language. The critical line of code will be line 13.
If you are not a ...
To keep reading, please go to the original article at:
æternity blog - Medium