2.27 Security Checks

Zero-address Check

Also known as "the first category of security checks".

Remember that Ethereum addresses are 20 bytes in length and, if those 20 bytes all happen to be zeros (which is referred to as a zero address) that is treated specially in Solidity contracts and also in the context of the EVM (because the private key for a zero address is unknown so, if Ether or tokens are transferred to the zero address, then it is effectively the same as burning them or not being able to retrieve them in the future).

Similarly, setting access control roles within the context of smart contracts to the zero address will also not work because transactions can't be signed with the private key of the zero address, because nobody knows the private key.

Therefore zero addresses should be treated with a lot of extra care within smart contracts, and from a security perspective zero address checks should be implemented for all address parameters specifically for those that are user supplied in external or public functions.

tx.origin Check

Also known as "the second category of security checks".

Again, remember that Ethereum has two types of accounts: EOA and contract accounts. Transactions in Ethereum can only originate from EOAs, so tx.origin is representative of the EOA address where the transaction originated from, so in situations where smart contracts would like to determine if the message sender was a contract or whether it was an EOA, then checking if the message sender is equal to tx.origin is an effective way to do it.

There are some nuances in the usage of this, but at a high level this is a check that you may encounter in smart contracts and has security implications.

Arithmetic Check

Also known as "the second category of security checks".

We have talked about the concept of overflows and underflows. Just to refresh: where arithmetic is used with integers in Solidity, if the value of that integer variable exceeds the maximum that can be represented by that integer or goes below the lowest value that can be represented by that integer type, then it results in what is known as wrapping, where the value overflows from the maximum integer value of the type and becomes zero or underflows below the lowest value representable (which is typically zero) and becomes equal to the maximum value representable.

This can have big security implications because the values of those variables (maybe it's representing the balance of that account or something else within the context of the application logic) wraps around and becomes either zero or the maximum value, which can totally change the application logic that is working with them. So such overflows are underflows of balances or other accounting aspects related to such variables can and have resulted in critical vulnerabilities.

These checks until Solidity 0.8.0 had to be implemented by the developers themselves, either within their own smart contracts or by using OpenZeppelin's SafeMath library, which provided various arithmetic library functions for addition, subtraction, multiplication, division and so on... that implemented these checks in the library functions.

Solidity recognize this aspect of arithmetic checks and how they are used all over in most of the smart contracts because nearly every contract deals with such integers and therefore these checks, as of version 0.8.0, are checked by default for integer types. Furthermore, they can be overridden by the developer where that those checks are not necessary.

To sum it up: arithmetic checks are one of the most critical checks that one would encounter in Solidity contracts, and until version 0.8.0 you would see a an extensive use of SafeMath library from OpenZeppelin for doing so. From 0.8 0 onwards, these are implemented by default.