El lado oscuro de los estándares de código: solidificado

El estándar de token ERC20 es, con mucho, el patrón más exitoso en el ecosistema y se puede encontrar en casi todos los proyectos de Ethereum. Aumentó enormemente la velocidad de desarrollo de dapps compatibles, como billeteras e intercambios descentralizados. También afectó en gran medida el proceso de auditoría de contratos inteligentes, tanto para bien como para mal.

En Solidified, muchos contratos que auditamos tienen una parte del código que casi siempre se parece a esto

Eso es genial por muchas razones. Todos están familiarizados con él, saben cómo se supone que funciona, qué buscar, qué problemas de seguridad comunes buscar, etc.

Puede acelerar todo el proceso de auditoría, porque parece que ha sido auditado cientos de veces antes, y es un código tan conocido que es casi difícil equivocarse. ¿O es eso?

Los humanos son criaturas de hábitos. Nuestros cerebros están conectados para hacer que todo sea lo más automático posible, y ahí es donde surge el peligro. El sentimiento de familiaridad nos engaña para no pensar demasiado en piezas de código similares, después de todo, ya lo hemos auditado antes y sabemos dónde están los problemas.

Es muy tentador mirar esas funciones y asumir que son las mismas que todas las otras implementaciones de tokens, porque la mayoría de las veces, es lo mismo. Apuesto a que las funciones ERC20 son la parte en la que la mayoría de los auditores pasan menos tiempo.

La peor parte es que no es una elección consciente no tener cuidado, lo que lo hace aún más peligroso, porque ni siquiera tienes la sensación de que no fuiste lo suficientemente exhaustivo.

Vamos a jugar un juego. La implementación del token anterior podría o no tener un problema. Tómese cinco minutos para mirarlo y sacar sus propias conclusiones.

.

.

¡Alerta de spoiler!
Si adivinaste que es una ficha perfecta, adivinaste mal. Contiene un problema de última hora:

Las operaciones de suma y resta en las funciones de transferencias se cambian. El saldo se agrega al remitente y se elimina del destino. Es tan obvio pero tan oculto.

Un principiante que recién comienza a comprender el concepto de tokens probablemente pueda detectarlo con bastante rapidez. Pero para todos los que leen eso varias veces, es más difícil, porque es tan familiar que casi no lo leemos como es.

Este problema no está restringido a ERC20 y puede afectar cada pieza de código que se repite demasiadas veces. Otro gran ejemplo son las bibliotecas comunes de Safe Math. ¿Con qué frecuencia realmente los auditas?

El primer paso para evitar los mismos errores es darse cuenta de que los está cometiendo. Después de eso, generalmente sigo una regla simple. Cuando creo que he terminado de auditar una parte específica del código, no importa cuánto tiempo haya tomado, me obligo a pasar otro tiempo allí. Solo ser consciente de lo que se supone que estás leyendo es suficiente para no dejar que el hábito tome el control y haga suposiciones falsas.

Un buen consejo es tratar de explicarte qué está haciendo cada línea de código, en lugar de leer la función como un bloque. O escriba el código que está leyendo solo para obligarse a pasar por cada carácter. Casi todas las acciones que lo saquen de su mentalidad de auditoría regular deberían funcionar.

Cada auditoría que no encontró ningún problema en el código familiar es un incentivo subconsciente para no prestar tanta atención en la siguiente. Es una batalla constante con tu mente. La buena noticia es que se gana fácilmente con un poco de conciencia.