Optimización de Gas en Solidity: Buenas Prácticas para Smart Contracts

Introducción

La programación en Solidity es un poco diferente a otros lenguajes de programación, ya que cada acción que se realiza en ETH cuesta dinero. En mis más de 10 años de experiencia en el desarrollo de software, he trabajado con distintos lenguajes de programación, tratando de optimizar procesos y tener un alto rendimiento de los mismos.

Sodility y ETH son especiales, son como esos amigos que cuesta comprender, que debes dar vueltas y vueltas para poder entenderlos, pero que entre más interactúas con ellos, más vas aprendiendo y teniendo una mejor relación.

Quiero compartir algunas buenas prácticas que te van a ayudar para crear smart contracts en Sodility que consuman lo menos posible de gas. Estas prácticas han sido resultado de muchas lecturas, conversaciones con compañeros, revisiones de código. Por lo tanto, agradezco a la comunidad de ETH, que siempre entre todos estamos buscando mejores prácticas para crear smart contracts eficientes.

Buenas prácticas

Si no la ocupas, elimínala

En Ethereum, obtienes un reembolso de gas por liberar espacio de almacenamiento. Si ya no necesitas una variable, pues elimínala. Esto ayudará a mantener el tamaño de la cadena de bloques más pequeña. Nunca subestimes el impacto de borrar 2 ó 3 variables que no se usan, ya que esto será un precedente para evitar el ingreso de futuras variables sin razón de ser.

Menos llamadas externas = menos gas.

Cada llamada a un smart contract externo cuesta una relevante cantidad de gas. Para optimizar el uso de gas, es mejor llamar a una función y hacer que devuelva todos los datos que necesitas en lugar de llamar a una función separada para cada dato. Esto podría ir en contra de las mejores prácticas de codificación para otros lenguajes, pero Solidity es un caso especial. Entonces trata de obtener la mayor cantidad posible de información usando la menor cantidad posible de llamadas externas.

Usa menos tamaños fijos como strings

Básicamente, cualquier variable de tamaño fijo en Solidity es más barata que el tamaño variable. Entonces si puedes ajustar tus datos en 32 bytes, entonces debes usar el tipo de datos bytes 32 en lugar de bytes o strings, ya que es mucho más barato en Solidity.

Más barato usar mappings que Arrays

En mi experiencia como desarrollador, casi nunca he visto un lenguaje en el que las asignaciones son menos costosas que las matrices, pero bueno, cuando encontré a Solidity, eso cambió. En EVM, una matriz no se almacena secuencialmente en la memoria sino como un mapeo. Sin embargo, puedes empaquetar matrices pero no asignaciones. Por lo tanto, es más económico usar arreglos si usas elementos más pequeños como uint8 que se pueden agrupar. No puedes obtener la longitud de un mapeo o analizar todos sus elementos, por lo que según su caso de uso, es posible que te veas obligado a usar un Array aunque te cueste más (gas).

Usa el modificador de las funciones externas

Para todas las funciones públicas, los parámetros de entrada se copian en la memoria automáticamente y cuesta gasolina. Si tu función solo se llama externamente, entonces debes marcarla explícitamente como externa. Los parámetros de la función externa no se copian en la memoria, sino que se leen directamente desde los datos de la llamada. Esta pequeña optimización en tu código en Solidity puede ahorrarte mucho gas cuando los parámetros de entrada de la función son muchos.

Conclusiones

Estoy seguro que existen muchas otras prácticas que pueden ayudar a reducir el gas; pero espero que las mencionadas te puedan ayudar a crear smart contracts eficientes.