Técnicas de optimización del gas

¿Qué son las técnicas de optimización del gas?

Las técnicas de optimización del gas son métodos para reducir los recursos computacionales y el almacenamiento en blockchain que requiere una transacción de criptomonedas o un contrato inteligente.

En Ethereum y otras redes compatibles con EVM, cada operación de la Ethereum Virtual Machine tiene un coste de gas.

Consultar el almacenamiento de un contrato, cambiar el estado de la blockchain, copiar datos, llamar a otro contrato, emitir un evento y desplegar bytecode pueden consumir gas.

El usuario que envía una transacción suele pagar una comisión calculada según el gas cobrado y el precio efectivo del gas de la transacción.

La fórmula básica es: Comisión de la transacción = Gas cobrado × Precio efectivo del gas.

La optimización del gas reduce la parte de la fórmula correspondiente al gas cobrado.

No controla directamente el precio de mercado de cada unidad de gas, que cambia en función de la demanda de espacio en los bloques.

Un contrato bien optimizado puede reducir los costes de los usuarios, permitir que quepa más actividad en cada bloque, mejorar la fiabilidad de las transacciones y hacer más práctica una aplicación descentralizada durante periodos de alta demanda de la red.

Sin embargo, la optimización del gas nunca debe debilitar los controles de acceso, la seguridad aritmética, la protección frente a la reentrancia, la precisión contable ni otras propiedades de seguridad.

La mejor optimización suele consistir en un diseño más sencillo que realice menos trabajo, en vez de código complejo escrito únicamente para ahorrar unas pocas unidades de gas.

Por qué es importante optimizar el gas en el sector cripto

Cada operación on-chain innecesaria genera un coste para la persona o la aplicación que envía la transacción.

Una pequeña diferencia puede parecer insignificante en una sola transacción, pero puede ser importante cuando un contrato inteligente procesa miles o millones de interacciones.

Un menor consumo de gas puede abaratar las transferencias de tokens, las operaciones de finanzas descentralizadas, la actividad con NFT, las votaciones de gobernanza y los juegos blockchain.

Los contratos eficientes también pueden ser más fáciles de procesar para validadores y nodos, ya que requieren menos lecturas y escrituras de almacenamiento y menos pasos computacionales.

La optimización del gas es especialmente importante para las aplicaciones que ejecutan bucles repetidos, actualizan muchos saldos, crean contratos nuevos o llaman a varios sistemas externos en una sola transacción.

También es relevante para las estrategias automatizadas de criptomonedas, ya que unos costes de ejecución elevados pueden eliminar el beneficio previsto de una operación o liquidación.

La optimización del gas no puede garantizar que una transacción sea barata en moneda nacional, porque el precio del gas y el precio de mercado de la criptomoneda nativa aún pueden subir.

Reduce la cantidad de trabajo de red por la que debe pagar el usuario.

Comprender en qué se gasta el gas

Antes de modificar el código de un contrato inteligente, los desarrolladores deben comprender las principales fuentes de consumo de gas.

El almacenamiento persistente suele ser uno de los recursos más costosos, porque los datos resultantes deben permanecer en el estado de la blockchain.

La memoria contiene datos temporales utilizados durante una ejecución y, por lo general, es más barata que el almacenamiento persistente, aunque su coste aumenta a medida que se amplía el espacio de memoria asignado.

Los datos de calldata contienen entradas de transacciones o funciones externas y no se convierten en memoria modificable del contrato a menos que se copien.

El despliegue de un contrato consume gas al ejecutar el código de inicialización y almacenar el bytecode resultante en tiempo de ejecución.

Las llamadas a contratos externos generan costes adicionales de acceso a cuentas, codificación de argumentos, gestión de datos devueltos y trabajo realizado por el contrato llamado.

Los cálculos criptográficos, los registros de eventos, la creación de contratos y los bucles extensos también pueden contribuir considerablemente al consumo total de gas.

La documentación oficial sobre el gas de Ethereum explica cómo se utiliza el gas para medir el esfuerzo computacional que requieren las transacciones y las operaciones de EVM.

Medir el gas antes de optimizar

La optimización del gas debe empezar por la medición, no por las suposiciones.

Antes de modificar el código, los desarrolladores deben registrar el coste de despliegue y el coste en tiempo de ejecución de las funciones importantes.

Las pruebas deben cubrir tamaños de transacción realistas, el comportamiento habitual de los usuarios, las entradas máximas admitidas, las rutas de fallo y estados inusuales de la blockchain.

Una función barata con un elemento en una matriz puede volverse insegura o demasiado costosa con mil elementos.

Las capturas de gas permiten comparar los costes de las funciones entre distintas revisiones del código y detectar aumentos accidentales.

Las trazas de ejecución pueden mostrar qué códigos de operación, posiciones de almacenamiento, llamadas internas y llamadas externas consumen más gas.

El compilador de Solidity puede generar estimaciones de gas, tal como se describe en su documentación, pero algunas estimaciones pueden no estar disponibles o no ser fiables si la ejecución depende de bucles dinámicos o del comportamiento de contratos externos.

Las pruebas en una blockchain local o en una testnet pública mantenida pueden ofrecer mediciones más realistas.

Los desarrolladores deben optimizar las rutas costosas que realmente utilizan los usuarios, en lugar de dedicar tiempo a código que apenas se ejecuta.

Utilizar una versión actual del compilador de Solidity

Las versiones más recientes del compilador de Solidity suelen incluir mejoras en la generación de código, correcciones del optimizador, compatibilidad con nuevas instrucciones de EVM y correcciones de seguridad.

En julio de 2026, la versión 0.8.36 figuraba en el sitio web oficial de Solidity como la última versión publicada del compilador.

Antes de elegir un compilador para producción, los desarrolladores deben consultar el sitio web oficial de Solidity y la lista de errores conocidos del compilador.

La versión elegida debe fijarse en la configuración de compilación para que todos los desarrolladores, sistemas de prueba y procesos de despliegue generen bytecode coherente.

Utilizar una directiva pragma amplia sin controlar el entorno de compilación real puede hacer que distintas versiones del compilador generen código diferente.

Aun así, una versión más reciente del compilador debe probarse con atención, porque las optimizaciones y los cambios del lenguaje pueden afectar al bytecode, al coste de despliegue y al comportamiento del contrato.

Activar y configurar el optimizador de Solidity

El optimizador de Solidity simplifica expresiones, elimina operaciones innecesarias, combina cálculos repetidos y puede reducir tanto el bytecode de despliegue como el consumo de gas en tiempo de ejecución.

La documentación del optimizador de Solidity explica que la optimización puede reducir el tamaño del código y el coste de ejecución.

El ajuste runs del optimizador expresa con qué frecuencia espera el desarrollador que se ejecute el código desplegado.

Un valor runs más bajo suele dar más importancia a que el bytecode de despliegue sea más pequeño.

Un valor runs más alto suele permitir que el compilador genere código que puede ocupar más espacio al desplegarse, pero resultar más barato en llamadas repetidas durante la ejecución.

No existe un valor runs universal que sea el mejor para todos los contratos de criptomonedas.

Un contrato que se despliega muchas veces pero se llama rara vez puede beneficiarse de una configuración distinta a la de un contrato que se espera que procese millones de transacciones.

Los desarrolladores deben comparar varias configuraciones con pruebas reales y evaluar el coste total durante todo el ciclo de vida, no solo el coste de despliegue o de ejecución.

El proceso de compilación via-IR puede generar optimizaciones distintas de las del proceso heredado, pero cualquier cambio de proceso debe tratarse como una modificación importante de la compilación y probarse exhaustivamente.

Reducir las escrituras en el almacenamiento persistente

Las escrituras en el almacenamiento persistente suelen ofrecer una de las mayores oportunidades para ahorrar gas.

Un contrato debe evitar almacenar información que pueda calcularse de forma segura a partir del estado existente o que el usuario pueda proporcionar cuando la necesite.

Debe evitarse escribir repetidamente el mismo valor si el contrato puede comprobar primero que no hace falta ningún cambio.

Un contrato que actualiza cinco variables de estado independientes puede ser más costoso que otro que utiliza un modelo contable más sencillo con menos escrituras.

Los desarrolladores también deben tener en cuenta si otros contratos inteligentes necesitan acceder a la información o si solo la necesitan las aplicaciones off-chain.

Los datos que deban afectar a la ejecución futura de un contrato suelen tener que almacenarse de forma persistente.

La información que solo necesiten las wallets, las interfaces o las herramientas de análisis a veces puede registrarse en un evento.

Eliminar datos almacenados puede generar un reembolso limitado de gas conforme a las reglas actuales de Ethereum, pero el reembolso tiene un límite y no debe considerarse una forma de hacer gratuito el almacenamiento.

Los contratos deben eliminar el estado obsoleto por razones sólidas de diseño, no crear datos innecesarios con la esperanza de recibir un reembolso más adelante.

Almacenar en caché lecturas repetidas del almacenamiento

Leer repetidamente una posición de almacenamiento es más costoso que leerla una vez y reutilizar un valor local, siempre que el estado subyacente no tenga que cambiar entre las lecturas.

Ethereum distingue entre accesos fríos y cálidos al estado conforme a EIP-2929.

El primer acceso a una posición de almacenamiento que no se haya consultado antes en una transacción es frío y tiene un coste mayor.

Los accesos posteriores a la misma posición durante esa transacción son cálidos y cuestan menos.

Incluso una lectura cálida del almacenamiento puede ser más costosa que utilizar un valor de la pila o de la memoria que ya esté disponible para la función.

A menudo, una función puede copiar una variable de estado de uso frecuente a una variable local, realizar sus cálculos y escribir el resultado final una sola vez.

Este método no debe utilizarse si una llamada externa puede cambiar el estado pertinente o si el valor almacenado en caché podría quedar desactualizado.

Los desarrolladores deben seguir los principios de comprobaciones, efectos e interacciones y analizar cuidadosamente la reentrancia antes de almacenar el estado en caché en torno a llamadas externas.

Empaquetar las variables de estado con cuidado

El almacenamiento de Ethereum se organiza en posiciones de 32 bytes.

Varias variables pequeñas de tipo valor pueden compartir una posición si el orden y el tamaño total permiten empaquetarlas.

Por ejemplo, varios valores enteros pequeños o booleanos pueden ocupar una sola posición en lugar de varias.

La documentación de Solidity sobre la disposición del almacenamiento explica cómo afectan las variables, las estructuras, las matrices, la herencia y el empaquetado a la asignación de posiciones.

Por tanto, el orden de las variables puede cambiar el número de posiciones que necesita un contrato.

Sin embargo, utilizar el entero más pequeño posible no siempre es más barato.

La EVM suele realizar operaciones aritméticas con palabras de 256 bits, por lo que los tipos de entero más pequeños pueden requerir operaciones adicionales de enmascaramiento o conversión.

El empaquetado ofrece la ventaja más clara cuando se suelen leer o escribir juntos varios valores empaquetados.

Actualizar un solo valor dentro de una posición empaquetada puede requerir leer la posición, modificar parte de la palabra y volver a escribir el valor combinado.

La disposición del almacenamiento también forma parte de la compatibilidad de los contratos actualizables, por lo que los desarrolladores no deben reordenar variables de estado existentes después del despliegue solo para ahorrar gas.

Utilizar variables constant e immutable

Un valor que nunca cambia después de la compilación normalmente debe declararse

cuando Solidity lo permita.

Un valor que se elige al construir el contrato, pero permanece fijo después, puede declararse

.

Las constantes y las variables inmutables evitan el acceso normal al almacenamiento persistente porque sus valores se integran en el código o se almacenan con él.

La documentación oficial de Solidity sobre variables de estado constant e immutable explica en qué se diferencian de las variables de estado ordinarias.

Entre los ejemplos habituales se incluyen valores de configuración fijos, direcciones permanentes, constantes matemáticas y límites que no pueden cambiar después del despliegue.

Una variable no debe hacerse inmutable si la aplicación realmente necesita que la gobernanza u otro proceso autorizado pueda actualizarla.

Eliminar flexibilidad necesaria solo para ahorrar gas puede crear un problema operativo mayor más adelante.

Utilizar calldata para entradas externas de solo lectura

Los argumentos de funciones externas que no necesitan modificarse pueden utilizar a menudo la ubicación de datos

.

Calldata es de solo lectura y evita copiar toda la entrada a la memoria al inicio de la ejecución.

La guía de Solidity sobre ubicaciones de datos recomienda utilizar calldata cuando sea posible, ya que evita copias e impide la modificación.

Esta técnica resulta especialmente útil para matrices, secuencias de bytes, cadenas de texto y estructuras que se pasan a funciones externas.

La memoria sigue siendo adecuada cuando el contrato debe modificar los datos o construir un nuevo valor en memoria.

Los desarrolladores no deben asumir que cambiar un parámetro de función de

a un entero más pequeño reduce automáticamente el tamaño de calldata.

La codificación ABI estándar suele colocar los valores estáticos en palabras de 32 bytes, y los tipos más pequeños pueden requerir trabajo adicional de conversión o validación.

Los ahorros de gas deben confirmarse mediante mediciones, no deducirse únicamente del nombre del tipo en el código fuente.

Minimizar los datos de calldata de las transacciones

Cada byte incluido en los datos de calldata de una transacción contribuye a su coste intrínseco.

Las matrices innecesarias, los campos duplicados, las cadenas de texto largas y las codificaciones ineficientes pueden encarecer las transacciones de los usuarios.

A veces, los desarrolladores pueden sustituir valores completos repetidos por identificadores compactos que el contrato vincula a una configuración almacenada.

También pueden evitar enviar información que el contrato pueda obtener de forma segura a partir del estado existente o del remitente de la transacción.

La compresión puede ayudar en sistemas especializados, pero la descompresión consume gas y puede eliminar el ahorro previsto.

Pectra activó EIP-7623, que introdujo un límite mínimo más alto para las transacciones con gran cantidad de datos.

Esto hace que la eficiencia de calldata sea especialmente relevante para las transacciones que transportan grandes cantidades de datos y realizan relativamente poca ejecución de EVM.

Los desarrolladores deben comparar el coste de calldata compacta con el trabajo de ejecución adicional que requiere su decodificación.

Utilizar almacenamiento transitorio para el estado limitado a una transacción

El almacenamiento transitorio permite a los contratos guardar valores que permanecen disponibles durante las llamadas internas de una transacción, pero que se borran automáticamente cuando esta termina.

Ethereum introdujo los códigos de operación

y mediante EIP-1153.

El almacenamiento transitorio es más barato que el persistente porque no pasa a formar parte del estado permanente de la blockchain.

Un uso habitual es un bloqueo de reentrancia que solo se necesita mientras se ejecuta una transacción.

Las versiones actuales de Solidity admiten variables de estado de tipo valor transitorias cuando los contratos se destinan a la EVM de Cancun o a una versión compatible más reciente.

El almacenamiento transitorio no debe utilizarse para información que tenga que conservarse para una transacción posterior.

También es necesario comprender bien su comportamiento con las llamadas, las llamadas delegadas y los contratos componibles.

La documentación de Solidity sobre almacenamiento transitorio advierte que el estado transitorio se limita a una transacción y tiene reglas específicas de propiedad entre los distintos tipos de llamada.

Los desarrolladores no deben sustituir un mecanismo de seguridad probado por almacenamiento transitorio hasta que la nueva implementación se haya probado y auditado exhaustivamente.

Utilizar errores personalizados en vez de cadenas revert largas

Los errores personalizados son una forma eficiente de devolver información estructurada sobre un fallo.

Una cadena de revert larga forma parte del bytecode desplegado del contrato y genera datos de retorno codificados cuando se produce un fallo.

Un error personalizado utiliza un selector de cuatro bytes y los parámetros declarados, lo que puede reducir el tamaño del despliegue y el coste de las rutas de fallo.

La documentación de Solidity sobre errores personalizados los describe como un mecanismo de error práctico y eficiente en términos de gas.

Los nombres y parámetros de los errores deben ser lo bastante claros para que wallets, desarrolladores y sistemas de supervisión puedan diagnosticar el problema.

Eliminar toda la información útil de los errores puede ahorrar una pequeña cantidad de gas, pero también dificultar mucho la investigación de las transacciones de criptomonedas fallidas.

Optimizar los bucles y el procesamiento de matrices

Los bucles pueden llegar a ser extremadamente costosos cuando el número de iteraciones depende de una matriz o colección almacenada que puede crecer sin un límite estricto.

Un bucle sin límite puede acabar requiriendo más gas del que puede proporcionar una transacción, lo que inutilizaría una función importante del contrato.

Siempre que sea posible, las cargas de trabajo grandes deben dividirse en lotes limitados.

A veces, un bucle que consulta repetidamente en el almacenamiento la longitud de una matriz puede guardar esa longitud en una variable local.

También se pueden almacenar en caché los valores de almacenamiento utilizados en cada iteración, siempre que hacerlo sea seguro.

Los desarrolladores pueden utilizar aritmética

para el contador de un bucle solo si pueden demostrar que es imposible que se desborde.

Los compiladores modernos de Solidity ya optimizan varios patrones habituales de bucles, por lo que cualquier cambio manual debe someterse a pruebas de rendimiento antes de adoptarse.

Procesar el trabajo en varias transacciones puede mejorar la fiabilidad, pero el contrato debe registrar el progreso de forma segura y evitar que se omitan, dupliquen o reordenen tareas.

Evitar llamadas externas redundantes

Llamar a otro contrato consume gas y expone la transacción al comportamiento de ejecución del contrato llamado.

Una función debe evitar solicitar varias veces el mismo valor externo si puede realizar una llamada segura y reutilizar el resultado.

A veces, se pueden combinar varias acciones relacionadas en una sola llamada a un contrato.

Sin embargo, la agrupación aumenta la cantidad de trabajo que puede fallar de forma conjunta y puede generar un payload de calldata mayor.

Las llamadas externas también pueden permitir la reentrancia, devolver datos inesperados, consumir mucho gas o revertir la transacción completa.

El ahorro de gas nunca debe justificar eliminar las comprobaciones de los valores devueltos ni la gestión segura de las llamadas.

Los desarrolladores deben decidir si un valor externo almacenado en caché seguirá siendo válido durante toda la ejecución y si el sistema externo puede cambiarlo mediante una llamada de retorno.

Utilizar eventos en lugar de almacenamiento cuando sea adecuado

Los eventos registran información en los logs de las transacciones y las aplicaciones off-chain pueden indexarlos.

A menudo, resultan menos costosos que almacenar información equivalente en el estado del contrato.

Los eventos son adecuados para historiales de actividad, notificaciones de interfaces, análisis y registros que la ejecución futura de un contrato inteligente no necesite consultar.

Los eventos no sustituyen al estado que determina saldos, titularidad, permisos, deuda, colateral u otros comportamientos del contrato.

Por lo general, los contratos inteligentes no pueden recuperar logs históricos durante la ejecución normal de la EVM.

Un sistema que almacenase información contable esencial únicamente en eventos necesitaría un servicio off-chain para reconstruirla y no podría hacerla cumplir directamente on-chain.

Los parámetros de los eventos también deben diseñarse con cuidado, ya que los temas indexados y los datos de los logs tienen costes de gas y propiedades de búsqueda distintos.

Reducir el tamaño de despliegue del contrato

El despliegue de un contrato conlleva un coste por ejecutar la lógica de inicialización y almacenar el bytecode en tiempo de ejecución.

Las funciones no utilizadas, la lógica duplicada, las cadenas de revert largas y los datos integrados pueden aumentar el coste del despliegue.

Los desarrolladores deben eliminar código muerto y evitar importar bibliotecas grandes cuando solo se necesita una parte pequeña.

Las bibliotecas externas pueden reducir la duplicación de bytecode entre despliegues, aunque llamarlas puede añadir costes en tiempo de ejecución y dependencias operativas.

Los patrones de fábrica y de clonación pueden reducir el coste de desplegar muchas instancias de contratos similares al compartir el código de implementación.

Los patrones proxy pueden permitir actualizaciones y despliegues repetidos, pero añaden el coste de las llamadas delegadas y generan consideraciones importantes de almacenamiento, gobernanza y seguridad.

Ethereum limita el bytecode ordinario en tiempo de ejecución desplegado mediante EIP-170, mientras que EIP-3860 mide y limita el código de inicialización.

Dividir el código únicamente para mantenerse por debajo de un límite de tamaño puede aumentar los costes de las llamadas, por lo que la arquitectura debe evaluarse durante todo el ciclo de vida del contrato.

Elegir como objetivo la versión correcta de EVM

El resultado del compilador depende de la versión de EVM seleccionada.

Un compilador dirigido a una EVM más reciente puede utilizar instrucciones no disponibles en una red antigua.

Por ejemplo, Shanghai introdujo la instrucción

mediante EIP-3855, que permite introducir el valor cero con una instrucción más pequeña y barata.

Dencun introdujo

mediante EIP-5656, proporcionando un método más eficiente para copiar datos en memoria.

Los compiladores modernos pueden utilizar estas instrucciones automáticamente si se configuran para una red compatible.

Normalmente, los desarrolladores no deben reproducir manualmente en ensamblador estas optimizaciones del compilador.

Un contrato compilado para una actualización del protocolo que aún no se haya activado en la red de destino podría no desplegarse o ejecutarse correctamente.

Por tanto, los sistemas de compilación deben establecer la versión de EVM correcta para cada cadena de destino.

Valorar las listas de acceso solo después de probarlas

Las listas de acceso permiten a una transacción identificar las cuentas y las claves de almacenamiento a las que espera acceder.

Los elementos incluidos en la lista se consideran cálidos al comenzar la ejecución, lo que reduce el coste posterior de acceso en frío.

EIP-2930 cobra por cada dirección y clave de almacenamiento incluidas en la lista.

Una lista de acceso precisa puede reducir el coste de ciertas transacciones previsibles.

Una lista incompleta o innecesaria puede aumentar la comisión total, ya que el usuario paga por elementos que ofrecen muy poca ventaja o que no se utilizan.

Puede resultar difícil generar listas de acceso cuando la ruta exacta de ejecución depende de cambios en el estado de la blockchain.

En lugar de asumir que precargar el estado siempre es más barato, los desarrolladores deben simular la transacción completa con y sin lista de acceso.

Agrupar las acciones de los usuarios con cuidado

Combinar varias acciones en una sola transacción puede evitar pagar varias veces los costes generales de las transacciones.

Por ejemplo, una aplicación puede permitir que un usuario autorice una acción y la ejecute mediante un flujo de trabajo coordinado.

Pectra activó EIP-7702, que permite a las cuentas controladas externamente delegar la ejecución a código de contratos inteligentes y admite funciones de wallet como la agrupación de operaciones y el patrocinio de comisiones de gas.

La agrupación no reduce automáticamente todos los componentes del coste de ejecución, porque cada acción sigue realizando el trabajo necesario de su contrato.

Un lote grande puede superar los límites prácticos de gas, generar más datos de calldata o hacer que todas las acciones se reviertan si falla un paso.

Las aplicaciones deben definir si se permite completar parcialmente las operaciones y cómo se notifican las subacciones fallidas.

La autorización de la wallet y el código delegado deben revisarse con cuidado, ya que los sistemas de agrupación pueden obtener amplias facultades sobre los activos del usuario.

Utilizar redes de capa 2 cuando sea adecuado

La optimización a nivel de aplicación reduce el número de unidades de gas consumidas, mientras que una red de capa 2 puede reducir el precio que pagan los usuarios por la ejecución y los datos.

Los rollups procesan actividad fuera de la mainnet de Ethereum y publican datos o pruebas en Ethereum.

Dencun introdujo transacciones con blobs mediante EIP-4844, que proporcionan a los rollups un canal de datos temporal y más especializado.

Pectra y Fusaka ampliaron posteriormente las capacidades de Ethereum de escalado y disponibilidad de datos.

La guía actual de Ethereum para desarrolladores explica cómo las actualizaciones recientes han cambiado las comisiones de la mainnet, las capacidades de las cuentas y la economía de los rollups.

Desplegar en una red de capa 2 no elimina la necesidad de optimizar los contratos, ya que el almacenamiento y los cálculos innecesarios siguen aumentando las comisiones de los usuarios y reduciendo la capacidad.

Antes de elegir una red, los desarrolladores también deben evaluar los requisitos de bridges, retiradas, liquidez, seguridad e interoperabilidad.

Utilizar ensamblador inline solo cuando sea necesario

El ensamblador inline puede proporcionar a los desarrolladores un control preciso de las operaciones de EVM y, en ocasiones, reducir el consumo de gas.

También elimina o elude algunas comprobaciones de tipos, protecciones de memoria y funciones de seguridad de alto nivel de Solidity.

Una rutina breve de ensamblador puede resultar difícil de entender para quienes la revisan y provocar corrupción de memoria, codificación incorrecta o llamadas inseguras.

Es posible que el compilador ya transforme Solidity normal en código tan eficiente como una implementación manual.

Por tanto, el ensamblador debe reservarse para cuellos de botella medidos, criptografía especializada, procesamiento de datos de bajo nivel o funcionalidades que Solidity no pueda expresar de forma eficiente.

Toda optimización en ensamblador debe incluir pruebas que comparen sus resultados con una implementación de referencia clara.

La revisión de seguridad independiente es especialmente importante cuando el ensamblador controla saldos de tokens, firmas, permisos o llamadas externas.

No sacrificar la seguridad para ahorrar gas

Un contrato inteligente más barato no es mejor si puede hacer que los usuarios pierdan sus criptomonedas.

Los desarrolladores no deben eliminar controles de acceso, validación de entradas, protección frente a la reentrancia, comprobación de plazos, protección frente al deslizamiento ni controles contables solo para ahorrar gas.

La aritmética

solo debe utilizarse cuando se haya demostrado matemáticamente que el desbordamiento y el subdesbordamiento son imposibles en todas las condiciones alcanzables.

Combinar varias variables en un único valor comprimido puede ahorrar almacenamiento, pero aumentar la posibilidad de errores de manipulación de bits.

El uso de un proxy puede reducir los costes de despliegue, pero genera riesgos relacionados con la autoridad de actualización y las colisiones de almacenamiento.

El uso de una firma off-chain puede reducir las transacciones, pero exige gestionar correctamente los nonces, los vencimientos, la separación de dominios y la protección frente a la repetición.

Además del coste de gas, cada optimización debe evaluarse según su legibilidad, facilidad de auditoría, riesgo operativo y mantenimiento futuro.

Errores habituales al optimizar el gas

Un error habitual es elegir tipos de entero más pequeños sin empaquetarlos con otros valores.

La EVM funciona con palabras de 256 bits, por lo que un tipo más pequeño puede no reducir por sí solo el coste en tiempo de ejecución.

Otro error es copiar todos los datos de calldata a la memoria, aunque la función solo necesite leerlos.

Un tercer error consiste en borrar almacenamiento para buscar un reembolso y después tener que recrear el mismo estado.

Un cuarto error es utilizar un bucle sin límite en una matriz de almacenamiento que va creciendo.

Un quinto error es elegir un valor runs alto para el optimizador sin comparar el despliegue y el comportamiento en tiempo de ejecución.

Un sexto error es escribir ensamblador manualmente antes de perfilar el contrato.

Un séptimo error es asumir que una optimización seguirá siendo válida después de que una actualización del compilador o de la red cambie el comportamiento de los códigos de operación.

Un octavo error es medir solo las transacciones completadas e ignorar las costosas rutas de reversión.

Un noveno error es considerar que una estimación de gas más baja demuestra que dos implementaciones tienen la misma lógica de seguridad y de negocio.

Cómo crear un proceso de optimización del gas

Un proceso fiable comienza definiendo el comportamiento requerido y las propiedades de seguridad del contrato.

El equipo debe crear pruebas funcionales antes de intentar optimizaciones de bajo nivel.

A continuación, debe medir el coste del despliegue y el gas utilizado en las rutas de transacción importantes.

Mediante perfiles, se deben identificar las escrituras de almacenamiento, los bucles, las entradas de calldata y las llamadas externas más costosas.

Los desarrolladores pueden simplificar la arquitectura, reducir los cambios de estado, elegir ubicaciones de datos adecuadas y activar ajustes de optimización del compilador que se hayan probado.

Cada cambio debe medirse con respecto a la versión original y revisarse para detectar nuevos riesgos de seguridad.

Las pruebas de regresión de gas deben permanecer en el proyecto para evitar que el desarrollo posterior elimine los ahorros sin que nadie lo advierta.

El bytecode final para producción debe compilarse con una versión del compilador fijada, una configuración verificada, el objetivo de EVM correcto y versiones revisadas de las dependencias.

Los contratos de criptomonedas de gran valor deben someterse a una auditoría de seguridad independiente, aunque el código optimizado supere las pruebas internas.

Preguntas frecuentes

¿Cuál es la mejor técnica para optimizar el gas?

La técnica más eficaz suele ser reducir las operaciones de almacenamiento persistente y simplificar el trabajo on-chain que realiza cada transacción.

¿El optimizador de Solidity siempre reduce el consumo de gas?

No. Un ajuste del optimizador puede reducir el gas en tiempo de ejecución y aumentar el coste de despliegue, por lo que los desarrolladores deben probar el ciclo de vida completo del contrato.

¿Qué significa el ajuste runs del optimizador?

Indica al compilador con qué frecuencia espera el desarrollador que se ejecute el código en tiempo de ejecución e influye en el equilibrio entre el tamaño del despliegue y el coste de las ejecuciones repetidas.

¿El almacenamiento es más caro que la memoria?

Sí. Por lo general, el almacenamiento persistente es mucho más caro porque sus datos siguen formando parte del estado de la blockchain una vez finalizada la transacción.

¿Calldata es más barato que la memoria?

Calldata puede ser más barato para las entradas externas de solo lectura, porque el contrato puede acceder a ellas sin copiarlas primero a la memoria.

¿Los tipos de entero más pequeños siempre ahorran gas?

No. Son más útiles cuando se pueden empaquetar varios valores en una sola posición de almacenamiento, mientras que los enteros pequeños aislados pueden requerir conversiones adicionales.

¿Por qué deben almacenar en caché los valores del almacenamiento los desarrolladores?

El almacenamiento en caché puede evitar lecturas repetidas del almacenamiento cuando un valor no cambia y se puede reutilizar de forma segura desde la pila o la memoria.

¿Qué es el almacenamiento transitorio?

Es un almacenamiento de EVM limitado a una transacción que se borra automáticamente y puede utilizarse para guardar temporalmente información, por ejemplo, bloqueos de reentrancia, a menor coste.

¿Los errores personalizados son más baratos que las cadenas de revert?

Por lo general, los errores personalizados son más eficientes en términos de gas, porque utilizan un selector compacto y parámetros codificados en lugar de almacenar y devolver cadenas de texto largas.

¿Los eventos pueden sustituir al almacenamiento del contrato?

Los eventos solo pueden sustituir al almacenamiento si la ejecución futura del contrato inteligente no necesita consultar ni hacer cumplir la información.

¿Borrar almacenamiento reembolsa todo el gas que costó?

No. Los reembolsos por borrar almacenamiento son limitados y están sujetos al límite de reembolso de gas del protocolo.

¿Deben utilizar aritmética unchecked los desarrolladores para ahorrar gas?

La aritmética unchecked solo debe utilizarse cuando se haya demostrado que el desbordamiento o el subdesbordamiento son imposibles y la justificación de seguridad esté documentada y probada.

¿Agrupar transacciones siempre ahorra gas?

No. La agrupación puede reducir los costes generales repetidos de las transacciones, pero también puede añadir datos de calldata, complejidad de ejecución y riesgo de fallo total.

¿Una red de capa 2 puede sustituir a la optimización de contratos?

No. Las comisiones de red más bajas pueden reducir el coste para el usuario, pero los contratos ineficientes siguen malgastando capacidad de ejecución y costando más que los contratos optimizados de la misma red.

¿Las listas de acceso siempre reducen el consumo de gas?

No. Las entradas de las listas de acceso tienen un coste propio y pueden aumentar la comisión si son imprecisas o innecesarias.

¿El ensamblador inline siempre utiliza menos gas?

No. El compilador puede generar código igual de eficiente, mientras que un ensamblador inseguro puede introducir graves problemas de seguridad y mantenimiento.

¿Cómo pueden medir los desarrolladores el consumo de gas?

Pueden utilizar estimaciones del compilador, capturas de gas automatizadas, pruebas de transacciones locales, trazas de ejecución y herramientas de perfilado.

¿Por qué pueden cambiar los costes de gas después de una actualización de la red?

Las actualizaciones de Ethereum pueden añadir códigos de operación, cambiar el precio de operaciones existentes, modificar las reglas de calldata o incorporar funciones más eficientes de almacenamiento y memoria.

¿La optimización del gas puede evitar comisiones de red elevadas?

Reduce las unidades de gas consumidas, pero no puede impedir que suba el precio de mercado del gas cuando muchos usuarios compiten por el espacio de los bloques.

¿El contrato más barato siempre es el mejor?

No. La corrección, la seguridad, la legibilidad y la facilidad de mantenimiento son más importantes que los pequeños ahorros de gas.

Conclusión

Las técnicas de optimización del gas reducen los recursos computacionales, de almacenamiento, de calldata y de despliegue que necesitan los contratos inteligentes de criptomonedas.

Los mayores ahorros suelen proceder de minimizar las escrituras en el almacenamiento persistente, almacenar en caché de forma segura las lecturas, elegir ubicaciones de datos adecuadas, reducir los datos de calldata innecesarios y evitar llamadas externas redundantes.

Los compiladores modernos de Solidity pueden optimizar el bytecode automáticamente, pero los ajustes del optimizador deben elegirse mediante mediciones realistas, no mediante conjeturas.

Las funciones actuales de Ethereum, como el almacenamiento transitorio,

, , el código delegado de cuentas y los cambios en el precio de calldata, han modificado la forma en que los desarrolladores deben abordar la optimización.

Los desarrolladores deben utilizar la versión de EVM adecuada y mantener al día el compilador, las pruebas y sus conocimientos de las reglas del protocolo.

Técnicas como el empaquetado de variables, los errores personalizados, los bucles limitados, la agrupación, los eventos, las bibliotecas y el despliegue en capa 2 pueden reducir costes si encajan con el diseño de la aplicación.

Las listas de acceso, los proxies, el ensamblador inline, la aritmética unchecked y el almacenamiento comprimido requieren más precaución, porque un pequeño ahorro de gas puede introducir una complejidad o un riesgo importantes.

Cada optimización debe medirse durante el despliegue, la ejecución satisfactoria, las rutas de fallo y el uso del contrato a largo plazo.

Las comprobaciones de seguridad nunca deben eliminarse únicamente para reducir el consumo de gas indicado en un informe.

La estrategia de optimización del gas más sólida consiste en realizar únicamente el trabajo on-chain mínimo necesario para que las operaciones con criptomonedas sean seguras y verificables.