Por qué y cómo usar SafeMath en nuestros contratos?

Las auditorías de código son imprescindibles en cualquier ámbito IT, y más aún cuando a través de nuestro desarrollo pasan grandes montos de dinero. Los smart contracts no son la diferencia y requieren un exhaustivo análisis de sintaxis y lógica para asegurarnos que no tienen falla alguna.

Uno de los errores típicos es la utilización de operadores matemáticos sin un resguardo lógico ante una posible falla de cálculo.

function add(uint256 x, uint256 y) internal returns(uint256) {
  return x + y;
}

El caso anterior es inofensivo para la mayoría de los lectores, pero extremadamente peligroso si la suma entre x e y dá un valor máximo a 2^256–1. En este caso, la suma genera un overflow que la EVM es incapaz de resolver.

Para prevenir este tipo de errores, podemos modificar la función anterior por la siguiente.

function safeAdd(uint256 x, uint256 y) internal returns(uint256) {
  uint256 z = x + y;
  assert((z >= x) && (z >= y));
  return z;
}

Utilizando un assert prevenimos desde el comienzo la validez de la llamada sin involucrar un gasto de gas innecesario al usuario generador de la transacción.

People use it indiscriminately when it is not needed and create contracts that need more gas than necessary — someone at Stackoverflow

Es importante detectar dónde usar “safe” y dónde no, dependiendo del dominio de nuestro problema, ya que agregar esta verificación incrementar el gasto de gas para deployar y/o transaccionar.

Para terminar les comparto la librería SafeMath.sol desarrollada por OpenZeppelin para importar en nuestros contratos y no reinventar la rueda.