Optimización del gas

¿Qué es la optimización del gas?

La optimización del gas es el proceso de reducir los recursos de blockchain necesarios para desplegar o ejecutar un contrato inteligente de criptomonedas.

En Ethereum, cada transacción y cada operación de la Ethereum Virtual Machine consume una cantidad de gas medida.

El remitente de la transacción suele pagar una comisión de red calculada según el gas cobrado y el precio efectivo de cada unidad de gas.

El cálculo básico es: Comisión de la transacción = Gas cobrado × Precio efectivo del gas.

La optimización del gas reduce la cantidad de gas cobrada al hacer más eficientes el código del contrato, el uso del almacenamiento, los datos de la transacción y las rutas de ejecución.

No controla directamente el precio del gas, que cambia según la demanda de capacidad de la blockchain.

Un contrato correctamente optimizado puede abaratar las transferencias de tokens, las operaciones de finanzas descentralizadas, las acciones de gobernanza, la actividad con NFT y otras transacciones cripto.

Sin embargo, la optimización del gas nunca debe eliminar las comprobaciones de seguridad ni dificultar la comprensión del comportamiento del contrato.

El objetivo es realizar el mínimo trabajo on-chain que sea seguro y verificable para satisfacer las necesidades de la aplicación.

Cómo funciona la optimización del gas

Ethereum cobra distintas cantidades de gas por los diferentes tipos de trabajo computacional y relacionado con el estado.

Los cálculos sencillos suelen ser baratos, mientras que los cambios en el almacenamiento persistente, la creación de contratos, las operaciones criptográficas y las llamadas externas pueden ser bastante más costosos.

La documentación oficial sobre el gas de Ethereum explica que el gas mide el esfuerzo computacional necesario para procesar transacciones de blockchain.

La optimización del gas comienza por identificar las operaciones que más gas consumen y determinar si la aplicación puede realizar menos trabajo sin alterar el comportamiento previsto.

Un desarrollador puede reducir las lecturas repetidas del almacenamiento, combinar cambios de estado, acortar los datos de las transacciones, eliminar cálculos duplicados o utilizar funciones de EVM más eficientes.

El compilador también puede transformar el código fuente de Solidity en bytecode más eficiente.

Algunas optimizaciones reducen el coste de desplegar un contrato, mientras que otras reducen el coste de cada interacción de los usuarios.

El método más adecuado depende de cuántas veces se desplegará el contrato y de la frecuencia con la que se llamará a sus funciones.

Optimización del gas frente a optimización del precio del gas

La optimización del gas y la optimización del precio del gas abordan partes distintas de la comisión de una transacción.

La optimización del gas reduce el número de unidades de gas que consume la transacción.

La optimización del precio del gas intenta enviar la transacción cuando cada unidad de gas cuesta menos.

Un contrato que consume 100.000 unidades de gas sigue siendo computacionalmente más costoso que otro que realiza la misma tarea segura con 60.000 unidades.

Sin embargo, el contrato más barato puede seguir generando una comisión elevada en moneda nacional si hay congestión de la red o el valor de ETH es alto.

A veces, los usuarios pueden reducir el precio del gas esperando a que disminuya la demanda de la red, pero los desarrolladores controlan el consumo de gas mediante el diseño de contratos y aplicaciones.

Combinar ambos métodos puede reducir el coste total de la transacción de forma más eficaz que depender de uno solo.

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

Unos costes de transacción elevados pueden impedir que los usuarios interactúen con una aplicación de criptomonedas, aunque el servicio subyacente sea útil.

Una pequeña reducción de gas adquiere importancia económica cuando se ejecuta la misma función miles o millones de veces.

Un menor consumo de gas puede mejorar la accesibilidad para los usuarios con saldos cripto más pequeños.

También puede ayudar a que las transacciones urgentes compitan por su inclusión sin requerir una comisión total innecesariamente alta.

La eficiencia del gas es especialmente importante para las estrategias automatizadas de criptomonedas, porque los costes de ejecución pueden superar el beneficio previsto de una operación o liquidación.

Los contratos eficientes también utilizan menos capacidad limitada de los bloques, lo que permite que quepan más transacciones en los recursos disponibles de la red.

Por tanto, la optimización puede beneficiar tanto a los usuarios individuales como al ecosistema blockchain en general.

Medir el gas antes de modificar el código

Antes de decidir qué partes de un contrato deben optimizarse, los desarrolladores deben medir el consumo de gas.

El compilador puede simplificar código fuente que parezca ineficiente.

Un atajo a nivel de código fuente también puede generar bytecode más costoso que una implementación más clara.

Los informes de gas deben incluir el despliegue del contrato, las transacciones completadas, las transacciones revertidas, las entradas de tamaño máximo y las ramas de ejecución poco habituales.

Una función que resulta barata para un usuario puede volverse demasiado costosa cuando procesa una matriz grande o muchas entradas de almacenamiento.

Las capturas de gas automatizadas permiten comparar los costes entre revisiones de software y detectar aumentos inesperados.

Las trazas de ejecución permiten identificar códigos de operación costosos, posiciones de almacenamiento, ampliaciones de memoria y llamadas a contratos externos.

La documentación del compilador de Solidity describe las salidas disponibles del compilador, los ajustes de optimización y las estimaciones de gas.

Los desarrolladores deben considerar las estimaciones como una referencia, ya que los bucles dinámicos y las llamadas externas pueden hacer que el consumo exacto de gas dependa del estado de la blockchain.

Optimizar la arquitectura del contrato inteligente

Los mayores ahorros de gas suelen proceder de cambiar la arquitectura del contrato, no de reescribir expresiones individuales.

Un contrato que almacena información innecesaria seguirá siendo costoso, aunque su aritmética esté muy optimizada.

Los desarrolladores deben determinar qué información debe hacerse cumplir on-chain y cuál puede calcularse o indexarse fuera del contrato.

Los saldos esenciales, los permisos, los registros de titularidad y los datos de colateral suelen requerir un estado on-chain persistente.

La información de visualización, la actividad histórica y los análisis pueden ser adecuados para los logs de eventos si la ejecución futura del contrato no necesita consultarlos.

Los desarrolladores también deben valorar si varios cambios de estado pueden representarse con un único valor acumulado o índice contable.

Los modelos de estado más sencillos suelen requerir menos operaciones de almacenamiento y son más fáciles de auditar.

Reducir las escrituras en el almacenamiento persistente

El almacenamiento persistente es uno de los recursos más costosos disponibles para un contrato inteligente de Ethereum.

Los datos de almacenamiento siguen formando parte del estado de Ethereum una vez finalizada la transacción.

Los nodos de la red deben procesar y mantener cada valor de almacenamiento nuevo o modificado.

Un contrato debe evitar escribir información que pueda calcular de forma segura a partir del estado existente.

También debe evitar escribir un valor si el valor solicitado ya está almacenado.

A veces, se pueden sustituir varias actualizaciones intermedias por una única escritura final en el almacenamiento después de completar todos los cálculos.

Los desarrolladores no deben almacenar varias copias de los mismos datos, salvo que la duplicación aporte una ventaja necesaria de seguridad o rendimiento.

Reducir las escrituras de almacenamiento suele generar más ahorro que hacer pequeños cambios en las operaciones aritméticas.

Almacenar en caché lecturas repetidas del almacenamiento

Cargar repetidamente el mismo valor del almacenamiento puede malgastar gas si el valor no cambia durante la ejecución.

A menudo, un contrato puede cargar el valor una vez en una variable local y reutilizarlo en cálculos posteriores.

Ethereum aplica costes diferentes a los accesos fríos y cálidos al estado conforme a EIP-2929.

Por lo general, el primer acceso a una cuenta o posición de almacenamiento durante una transacción es más costoso que los accesos posteriores a la misma ubicación.

Sin embargo, incluso una lectura cálida del almacenamiento puede ser más costosa que utilizar un valor disponible en la pila o la memoria.

Debe evitarse el almacenamiento en caché si una llamada externa podría cambiar el estado pertinente del contrato antes de que se utilice el valor almacenado.

Siempre que se almacene el estado en caché durante una interacción externa, deben revisarse la reentrancia y el comportamiento de las llamadas de retorno.

Empaquetar variables de estado

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

Solidity puede colocar varias variables pequeñas de tipo valor en una misma posición si su tamaño y orden lo permiten.

La documentación oficial de Solidity sobre la disposición del almacenamiento explica cómo se asignan las variables a las posiciones de almacenamiento.

Un orden cuidadoso de las variables puede reducir el número de posiciones que necesita un contrato.

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

Utilizar un entero más pequeño no reduce automáticamente el gas en tiempo de ejecución, porque la EVM suele realizar operaciones aritméticas con palabras de 256 bits.

El empaquetado resulta más beneficioso cuando se suelen leer o escribir juntos varios valores empaquetados.

Actualizar un solo campo de una posición empaquetada puede requerir operaciones adicionales de enmascaramiento y combinación.

Los desarrolladores no deben reordenar las variables de almacenamiento existentes en un contrato actualizable, ya que podrían corromper los datos almacenados previamente.

Utilizar variables constant e immutable

Un valor que nunca cambia no debe almacenarse como una variable de estado mutable normal.

Solidity permite declarar los valores constantes durante la compilación mediante la palabra clave

.

Los valores que se eligen al construir el contrato y permanecen fijos después suelen poder declararse con la palabra clave

.

Las constantes y las variables inmutables evitan las lecturas de almacenamiento normales porque sus valores se integran o se referencian mediante el bytecode del contrato.

La documentación de Solidity sobre variables constant e immutable explica las diferencias entre estas declaraciones.

Algunos ejemplos habituales son las direcciones permanentes, los límites fijos, los valores matemáticos y la configuración que no puede modificarse después del despliegue.

Una variable debe seguir siendo mutable si la aplicación realmente necesita que la gobernanza o una administración autorizada pueda actualizarla.

Elegir la ubicación de datos adecuada

Los datos de Solidity pueden residir en el almacenamiento, la memoria, calldata o el almacenamiento transitorio, según el uso que se les vaya a dar.

El almacenamiento persiste entre transacciones y suele ser la ubicación más costosa.

La memoria es temporal y solo está disponible durante la ejecución actual.

Calldata contiene datos externos de solo lectura que se proporcionan con la transacción o la llamada al contrato.

El almacenamiento transitorio permanece disponible entre llamadas durante una transacción, pero se borra automáticamente cuando esta termina.

Elegir una ubicación de datos más costosa de lo necesario aumenta el coste de la transacción sin mejorar la funcionalidad.

La documentación de Solidity sobre ubicaciones de datos explica cómo afectan estas ubicaciones a la copia, la mutabilidad y la duración de los datos.

Utilizar calldata para entradas externas de solo lectura

Los parámetros de funciones externas que no necesitan modificarse pueden permanecer a menudo en calldata.

Utilizar calldata puede evitar copiar matrices, cadenas de texto, secuencias de bytes o estructuras grandes a la memoria.

Esto puede reducir el consumo de gas si la función solo necesita examinar los valores enviados.

La memoria sigue siendo adecuada cuando el contrato debe modificar la entrada o crear un nuevo valor en memoria.

Los desarrolladores también deben minimizar los datos innecesarios de las transacciones, porque cada byte de calldata contribuye al coste de gas intrínseco.

A veces, se pueden sustituir valores repetidos por identificadores compactos cuando el contrato ya almacena toda la configuración.

La compresión debe medirse con cuidado, porque la computación necesaria para decodificar los datos puede superar el ahorro obtenido.

Tener en cuenta el precio actual de calldata

La actualización Pectra de Ethereum se activó el 7 de mayo de 2025 e incluyó cambios que afectan a la economía de las transacciones con gran cantidad de datos.

EIP-7623 introdujo un límite mínimo de gas más alto para las transacciones que incluyen grandes cantidades de calldata y realizan relativamente poca ejecución de EVM.

La regla se diseñó para limitar el tamaño máximo de los bloques con gran cantidad de datos y mejorar la resiliencia de la red.

Los desarrolladores no deben asumir que una transacción con un mínimo de computación será siempre barata si incluye un gran payload de calldata.

Las aplicaciones que envían pruebas, firmas, lotes o información comprimida de transacciones deben evaluar el comportamiento actual del protocolo mediante pruebas de rendimiento.

Las nuevas actualizaciones de la red pueden cambiar el coste relativo de calldata, la computación, el almacenamiento y otros recursos.

Utilizar almacenamiento transitorio cuando el estado sea temporal

El almacenamiento transitorio está pensado para información que debe permanecer disponible durante una transacción, pero que no debe persistir después.

Ethereum introdujo los códigos de operación

y mediante EIP-1153.

Los valores transitorios se descartan automáticamente al final de la transacción.

Esto hace que el almacenamiento transitorio sea más barato que el persistente, porque no es necesario guardar los datos de forma permanente.

Un caso de uso habitual es un bloqueo de reentrancia compartido entre varias llamadas internas o externas durante una transacción.

El almacenamiento transitorio también puede admitir contabilidad temporal, llamadas de retorno y permisos limitados a una transacción.

No puede sustituir al almacenamiento de saldos ni a la información que deba seguir disponible en una transacción posterior.

Antes de utilizarlo en aplicaciones cripto componibles, los desarrolladores deben entender su comportamiento en llamadas normales y llamadas delegadas.

Utilizar el optimizador de Solidity

El optimizador de Solidity puede simplificar expresiones, eliminar operaciones innecesarias, combinar cálculos y reducir el tamaño del bytecode.

La documentación oficial del optimizador de Solidity describe varias etapas de optimización que se aplican al código generado.

El optimizador puede reducir el gas de despliegue, el gas en tiempo de ejecución o ambos.

El ajuste runs representa una estimación de la frecuencia con la que se espera ejecutar el código desplegado.

Por lo general, un valor runs más bajo da prioridad a un bytecode de despliegue más pequeño.

Por lo general, un valor runs más alto permite un despliegue mayor a cambio de que las ejecuciones repetidas sean más baratas.

No existe un ajuste runs ideal para todos los contratos inteligentes.

Los desarrolladores deben comparar las configuraciones según las expectativas reales de despliegue y uso del contrato.

El proceso de compilación basado en IR puede generar resultados distintos de los del proceso anterior y debe evaluarse mediante pruebas completas.

Utilizar un compilador actual y verificado

Las versiones del compilador de Solidity pueden incluir mejoras de gas, compatibilidad con nuevas versiones de EVM, correcciones de errores y mejoras de seguridad.

Antes de elegir un compilador para un despliegue de producción, los desarrolladores deben consultar el sitio web oficial de Solidity.

La documentación de Solidity suele recomendar utilizar una versión actual publicada, salvo que el proyecto tenga un motivo específico de compatibilidad para no hacerlo.

Los desarrolladores también deben revisar la lista oficial de errores conocidos del compilador de Solidity.

La versión del compilador y los ajustes de optimización deben fijarse en el proceso de compilación.

Volver a compilar el mismo código fuente con otro compilador puede generar un bytecode y un comportamiento de gas diferentes.

Utilizar errores personalizados

Por lo general, los errores personalizados son más eficientes en términos de gas que las cadenas de revert largas.

Una cadena de revert aumenta el bytecode de despliegue y genera texto codificado cuando falla la transacción.

Un error personalizado utiliza un selector compacto y puede incluir parámetros estructurados.

La documentación de Solidity sobre errores personalizados explica cómo los contratos pueden definirlos y devolverlos.

Los errores deben seguir proporcionando información suficiente para que los usuarios, las wallets y los desarrolladores comprendan el fallo.

Eliminar información útil sobre fallos para ahorrar una cantidad muy pequeña de gas puede dificultar el soporte y la auditoría de la aplicación.

Optimizar los bucles

Los bucles pueden volverse peligrosamente costosos cuando el número de iteraciones depende de una colección que puede crecer sin un límite estricto.

Un bucle sin límite puede acabar necesitando más gas del que puede proporcionar una transacción.

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

Un bucle puede almacenar en caché la longitud de una matriz o un valor utilizado repetidamente si esa información no puede cambiar durante la ejecución.

A veces, los desarrolladores pueden utilizar aritmética unchecked para un contador de bucle cuando sea matemáticamente imposible que se desborde.

El código unchecked debe acompañarse de pruebas y de una explicación clara de su seguridad.

Los compiladores modernos ya optimizan muchos patrones habituales de bucles, por lo que los cambios manuales deben medirse, no darse por más baratos sin comprobarlos.

Reducir las llamadas a contratos externos

Las llamadas a contratos externos generan costes de acceso a cuentas, codificación de argumentos, procesamiento de datos devueltos y ejecución del contrato llamado.

Un contrato debe evitar llamar varias veces a la misma función externa cuando una única llamada segura puede proporcionar el valor necesario.

A veces se pueden combinar varias acciones relacionadas en una llamada o una transacción.

Sin embargo, la agrupación puede aumentar los datos de calldata, la complejidad de la ejecución y la cantidad de trabajo que se revierte si falla un paso.

Las llamadas externas también plantean cuestiones de seguridad relacionadas con la reentrancia, los datos devueltos maliciosos, el consumo de gas y los fallos inesperados.

La optimización del gas nunca debe eliminar las comprobaciones de los valores devueltos ni los patrones seguros de interacción.

Utilizar eventos en lugar de almacenamiento cuando sea adecuado

Los eventos pueden registrar actividad de la blockchain para wallets, interfaces, sistemas de análisis e indexadores off-chain.

A menudo son menos costosos que almacenar la misma información como estado persistente del contrato.

Los eventos son adecuados cuando la ejecución futura de los contratos inteligentes no necesita consultar ni hacer cumplir la información.

Los historiales de transacciones, las notificaciones de actividad y los metadatos descriptivos pueden ser adecuados para los logs.

Los saldos, los permisos, la deuda, el colateral y la titularidad no deben almacenarse únicamente en eventos, porque la ejecución normal de la EVM no puede buscar logs históricos.

El contrato debe conservar en un estado accesible toda la información necesaria para tomar decisiones futuras.

Reducir el coste de despliegue del contrato

Desplegar un contrato consume gas para la lógica de inicialización y para almacenar el bytecode en tiempo de ejecución.

Las funciones no utilizadas, el código duplicado, los datos integrados y los mensajes de error largos pueden aumentar el coste de despliegue.

Los desarrolladores deben eliminar el código inalcanzable y evitar importar bibliotecas grandes cuando solo sea necesaria una pequeña parte.

Las bibliotecas pueden reducir el bytecode duplicado en varios contratos, aunque las llamadas a bibliotecas externas generan costes en tiempo de ejecución y dependencias propios.

Los patrones de fábrica y de clonación pueden reducir los costes de despliegue cuando se necesitan muchas instancias de contratos similares.

Los patrones proxy también permiten compartir código de implementación, pero introducen costes de llamadas delegadas, permisos de actualización y riesgos relacionados con la disposición del almacenamiento.

La arquitectura debe elegirse según las necesidades de seguridad y del ciclo de vida, no únicamente en función del gas de despliegue.

Elegir como objetivo la versión correcta de EVM

El compilador de Solidity puede generar bytecode diferente según la versión de EVM seleccionada.

Las versiones más recientes de EVM pueden admitir instrucciones más eficientes que las redes antiguas no pueden ejecutar.

Por ejemplo, EIP-3855 introdujo la instrucción compacta

para introducir el cero en la pila.

EIP-5656 introdujo

para copiar memoria de forma más eficiente.

Los compiladores actuales pueden utilizar automáticamente las instrucciones admitidas si se configuran para la red correcta.

Un contrato compilado para una versión más reciente de EVM puede fallar en una red que aún no haya activado la actualización necesaria.

Por tanto, los desarrolladores deben seleccionar una versión de EVM compatible con la cadena de despliegue prevista.

Comprender los reembolsos de gas

Los reembolsos de gas pueden reducir la cantidad final de gas cobrada después de ciertas operaciones de almacenamiento que cumplen los requisitos.

Las reglas actuales de Ethereum limitan los reembolsos del protocolo al 20% del consumo bruto de gas.

EIP-3529 redujo el reembolso por borrar almacenamiento apto y eliminó el antiguo reembolso por

.

Borrar almacenamiento puede seguir ofreciendo una ventaja limitada, pero no hace que crear y eliminar estado sea gratuito.

Los desarrolladores no deben escribir datos innecesarios con la intención de eliminarlos más tarde para obtener un reembolso.

El reembolso también se aplica después de la ejecución, por lo que no puede evitar un fallo por falta de gas.

no es un método moderno para optimizar el gas y tiene un comportamiento restringido conforme a EIP-6780.

Valorar la agrupación con cuidado

Agrupar varias acciones en una transacción puede evitar pagar varias veces los costes generales de transacción.

También puede mejorar la experiencia del usuario al reducir el número de confirmaciones de la wallet.

Sin embargo, cada acción sigue consumiendo el gas necesario para su propia computación y sus cambios de estado.

Un lote grande puede acercarse a los límites de gas de la transacción o provocar un fallo costoso que revierta todas las acciones.

Las aplicaciones deben definir si las subacciones fallidas revierten todo el lote o permiten una ejecución parcial.

La autorización debe diseñarse con cuidado, porque una firma amplia para un lote puede permitir más acciones de las que el usuario espera.

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

La lógica delegada de las cuentas debe revisarse con el mismo cuidado que cualquier otro contrato que controle criptomonedas.

Utilizar redes de capa 2 para ahorrar más

La optimización de los contratos inteligentes reduce la cantidad de computación que necesita una aplicación.

Desplegar en una red de capa 2 adecuada puede reducir aún más el precio que se paga por esa computación y los datos asociados.

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

La actualización Dencun introdujo blobs mediante EIP-4844, proporcionando a los rollups un mercado de datos temporal e independiente.

Las comisiones más bajas de capa 2 no eliminan la necesidad de optimizar el gas, porque los contratos ineficientes siguen malgastando capacidad y costando más que los eficientes de la misma red.

Los desarrolladores también deben evaluar la seguridad de los bridges, las reglas de retirada, la liquidez, la finalidad y los cálculos de comisiones específicos de la red.

Evitar la optimización prematura de bajo nivel

Los desarrolladores no deben empezar con ensamblador inline o manipulación compleja de bits antes de medir el código normal de Solidity.

Es posible que el compilador ya genere bytecode eficiente a partir de una implementación clara de alto nivel.

En ocasiones, el ensamblador puede reducir el gas de operaciones especializadas, pero elude varias protecciones del lenguaje.

Los errores en el ensamblador pueden provocar corrupción de memoria, codificaciones incorrectas, llamadas inseguras o la pérdida de fondos de los usuarios.

Una optimización de bajo nivel debe contar con una implementación de referencia legible y pruebas que demuestren un comportamiento equivalente.

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

No sacrificar la seguridad para ahorrar gas

El contrato más barato no sirve de nada si los atacantes pueden robar sus criptomonedas.

Los controles de acceso, la validación de entradas, la protección frente a la reentrancia, las comprobaciones de deslizamiento y de plazos y los controles contables no deben eliminarse únicamente para reducir el consumo de gas.

La aritmética unchecked solo debe utilizarse cuando el desbordamiento y el subdesbordamiento sean imposibles en todas las condiciones alcanzables.

El almacenamiento comprimido puede ahorrar gas, pero aumentar la posibilidad de errores a nivel de bits.

Un proxy puede reducir el coste de despliegue, pero introducir un control centralizado de las actualizaciones o colisiones de almacenamiento.

Una firma off-chain puede eliminar una transacción, pero también introduce requisitos relativos al nonce, el vencimiento, la protección frente a la repetición y la separación de dominios.

Las decisiones de optimización deben revisarse teniendo en cuenta la seguridad, la legibilidad, la capacidad de actualización y el riesgo operativo.

Pruebas de optimización del gas

Toda optimización debe probarse comparándola con la implementación original.

Las pruebas funcionales deben confirmar que ambas versiones producen los mismos cambios de estado y resultados.

Las pruebas de gas deben medir el consumo medio, el consumo máximo admitido y las condiciones de fallo.

Las pruebas fuzz pueden explorar entradas inusuales que quizá revelen una ruta de ejecución costosa o incorrecta.

Las pruebas de invariantes pueden confirmar que las propiedades esenciales de contabilidad y seguridad siguen siendo ciertas después de la optimización.

Los desarrolladores también deben probar con la versión exacta del compilador, los ajustes del optimizador y el objetivo de EVM previstos para producción.

Deben conservarse las capturas de gas para que el desarrollo futuro no revierta la mejora sin que nadie lo advierta.

Errores habituales al optimizar el gas

Un error habitual es asumir que todos los tipos de entero más pequeños reducen el consumo de gas.

Otro error es copiar datos externos de solo lectura de calldata a la memoria sin una necesidad funcional.

Los desarrolladores también pueden crear bucles sin límite en colecciones de almacenamiento que se vuelven imposibles de ejecutar a medida que crece la aplicación.

Algunos equipos optimizan una función que apenas se utiliza e ignoran un pequeño coste que se repite en todas las transacciones de los usuarios.

Otros eligen los ajustes del optimizador sin probar el equilibrio entre el despliegue y la ejecución.

Puede añadirse ensamblador escrito a mano antes de identificar la operación que realmente resulta costosa.

Los desarrolladores también pueden basarse en calendarios de gas obsoletos después de que una actualización de Ethereum haya cambiado el precio de una operación.

El error más peligroso es eliminar una comprobación de seguridad necesaria para obtener una cifra de consumo de gas llamativa.

Cómo crear una estrategia de optimización del gas

Una estrategia de optimización del gas debe comenzar con una definición clara del comportamiento del contrato y de sus requisitos de seguridad.

El equipo de desarrollo debe crear pruebas completas antes de cambiar la implementación.

A continuación, debe medir los costes de despliegue y de transacción en condiciones realistas.

Se debe dar prioridad a las operaciones de almacenamiento, los bucles, los payloads de calldata y las llamadas externas más costosos.

Antes de reescribir código de bajo nivel, debe considerarse la simplificación de la arquitectura.

Los ajustes del compilador y la versión de EVM de destino deben probarse y documentarse.

Toda optimización debe someterse a una revisión funcional, de consumo de gas y de seguridad.

El despliegue final debe utilizar bytecode reproducible generado con herramientas y dependencias fijadas.

Preguntas frecuentes

¿Qué es la optimización del gas en términos sencillos?

Optimizar el gas consiste en reducir la computación, el almacenamiento y los datos de transacción de blockchain necesarios para ejecutar un contrato inteligente de forma segura.

¿La optimización del gas reduce el precio del gas?

No. Reduce el consumo de gas, mientras que el precio del gas viene determinado por la demanda de la red y la configuración de las comisiones de la transacción.

¿Cuál es la optimización del gas más eficaz?

Reducir las operaciones innecesarias de almacenamiento persistente y simplificar la arquitectura del contrato suele aportar los mayores ahorros.

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

Sí. Por lo general, el almacenamiento persistente es más caro porque sigue formando parte del estado de la blockchain cuando termina 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 no es necesario copiar todo el valor a la memoria.

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

No. Normalmente solo ofrecen un ahorro significativo de almacenamiento cuando se pueden empaquetar varios valores en una misma posición.

¿Qué es el almacenamiento transitorio?

Es un almacenamiento de EVM limitado a una transacción que se borra automáticamente y puede reducir el coste del estado temporal de los contratos.

¿El optimizador de Solidity siempre reduce los costes?

No. Una configuración del optimizador puede reducir el gas en tiempo de ejecución y aumentar el coste del despliegue, por lo que hay que medir cada configuración.

¿Qué significa optimizer runs?

El ajuste runs influye en el equilibrio que establece el compilador entre un bytecode de despliegue más pequeño y un menor coste de las ejecuciones repetidas.

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

Por lo general, los errores personalizados son más eficientes porque utilizan selectores compactos y parámetros codificados en vez de cadenas de texto largas.

¿Los eventos pueden sustituir al almacenamiento?

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

¿Borrar almacenamiento genera un reembolso de gas?

Borrar almacenamiento que cumpla los requisitos puede generar un reembolso limitado, pero este tiene un límite y no recupera el coste original completo del almacenamiento.

¿Un reembolso de gas puede evitar un fallo por falta de gas?

No. Los reembolsos de gas se calculan después de la ejecución y no pueden proporcionar gas adicional mientras se ejecuta la transacción.

¿Agrupar transacciones siempre ahorra gas?

No. La agrupación puede reducir los costes generales repetidos de las transacciones, pero también puede aumentar los datos de calldata, la complejidad y el riesgo de fallo.

¿Deben utilizar los desarrolladores ensamblador inline para optimizar?

El ensamblador inline solo debe utilizarse para cuellos de botella medidos, porque puede introducir graves riesgos de seguridad y mantenimiento.

¿Las redes de capa 2 pueden sustituir a la optimización del gas?

No. Las redes de capa 2 pueden reducir las comisiones, pero los contratos ineficientes siguen consumiendo más recursos que los contratos optimizados de la misma red.

¿Por qué pueden cambiar los costes del gas con el tiempo?

Las actualizaciones de Ethereum pueden incorporar nuevos códigos de operación, cambiar el precio de operaciones existentes, modificar las reglas de calldata o ampliar la capacidad de la red.

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

Pueden utilizar informes de gas, recibos de transacciones, trazas de ejecución, resultados del compilador, capturas automatizadas y pruebas realistas.

¿La implementación con el menor consumo de gas siempre es la mejor?

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

¿Pueden los usuarios optimizar el gas sin cambiar un contrato?

Los usuarios pueden elegir periodos de menor demanda o redes adecuadas, pero solo el desarrollador del contrato puede cambiar la eficiencia de ejecución subyacente de la aplicación.

Conclusión

La optimización del gas es el proceso de ingeniería que reduce los recursos consumidos por los contratos inteligentes y las transacciones de criptomonedas.

Reduce el consumo de gas, pero no cambia directamente el precio de mercado de cada unidad de gas.

Las optimizaciones más importantes suelen proceder de simplificar la arquitectura, reducir las operaciones de almacenamiento, elegir ubicaciones de datos eficientes, limitar los bucles y reducir las llamadas externas.

La optimización del compilador, las constantes, los valores inmutables, los errores personalizados, el empaquetado de variables, el almacenamiento transitorio y una agrupación adecuada pueden aportar ahorros adicionales.

Los desarrolladores deben utilizar un compilador actual, consultar los errores conocidos del compilador y elegir la versión de EVM correcta.

Toda optimización debe probarse con transacciones completadas, fallos, entradas grandes y rutas de ejecución inusuales.

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

Un contrato bien optimizado realiza únicamente el trabajo on-chain necesario para ofrecer funciones de criptomonedas seguras, transparentes y fiables.