The dark side of code standards
An observation on how common patterns can affect the auditing process of smart contracts.
The ERC20 token standard is by far the most successful pattern in the ecosystem and can be found in almost every Ethereum project. It massively increased the development speed of compatible dapps, such as wallets and decentralized exchanges. It also greatly affected the process of auditing smart contracts, both for good and for bad.
The Good side of standards
At Solidified,many contracts we audit have a part of the code that almost always looks similar to this
That’s great for many reasons. Everyone is familiar with it, they know how it is supposed to work, what to look for, what common security issues to look for and so on.
It can make the whole audit process faster, because it feels like it’s been audited a hundred times before, and is such a known piece of code that it’s almost hard to get it wrong. Or is it?
The dark side of standards
Humans are creatures of habit. Our brains are wired to make everything as automatic as possible, and that’s where the danger arises. The feeling of familiarity tricks us into not putting much thought on similar pieces of code, after all, we’ve audited that before and know where the problems are.
It is very tempting to look at those functions and assume that they are the same as all the other token implementations, because most of the time, it’s just the same. I bet the ERC20 functions are the part most auditors spend the least time on.
The worst part of it is that it’s not a conscious choice to not be careful, which makes it even more dangerous, because you don’t even get the feeling that you were not thorough enough.
The devil is in the details
Let’s play a game. The token implementation above might or might not have an issue. Take five minutes to look at it and draw your own conclusions.
.
.
Spoiler alert!
If you guessed that it is a perfect token, you guessed wrong. It contains a breaking issue:
The sum and subtraction operations on the transfers functions are switched. Balance is being added to the sender and removed from the destination. It’s so obvious yet so hidden.
A beginner that is just starting to understand the concept of tokens can probably spot it fairly quickly. But for everyone that read that multiple times, it’s harder, because it is so familiar that we almost don’t read it as it is.
This issue is not restricted to ERC20 and can affect every piece of code that is repeated too many times. Another great example are the common Safe Math libraries. How often do you really audit them??
How to fight it
The first step in avoiding the same mistakes is realizing that you’re making them. After that, I usually follow one simple rule. When I think I’m done auditing a specific part of the code, no matter how long it took, I force myself to spend another extra time there. Just being conscious of what you’re supposed to be reading is enough to not let the habit take over and make false assumptions.
A good tip is to try to explain to yourself what each single line of code is doing, instead of reading the function as a block. Or type the code that you’re reading just to force yourself to go through every single character. Almost every action that takes you out of your regular auditing mindset should work.
Every audit that found no issue in the familiar code is a subconscious incentive to not pay that much attention in the next one. It’s a constant battle with your mind. The good news is that it’s easily won with a bit of awareness.
