Gas golfing

¿Qué es el gas golfing?

El gas golfing consiste en realizar pequeños cambios muy específicos en el código de un contrato inteligente para reducir su consumo de gas.El término se inspira en el code golf, un reto de programación en el que los desarrolladores intentan resolver un problema con la menor cantidad posible de código fuente.En el desarrollo de criptomonedas, el objetivo no es necesariamente escribir el menor número de caracteres.El objetivo es generar bytecode que consuma menos recursos de la blockchain y mantenga el comportamiento requerido del contrato.El gas golfing suele asociarse principalmente a Ethereum y a otras redes que ejecutan contratos inteligentes mediante la Ethereum Virtual Machine.Los desarrolladores pueden optimizar el gas de un contrato reduciendo las operaciones de almacenamiento, simplificando los cálculos, acortando los datos de reversión, evitando copias de memoria innecesarias o eligiendo instrucciones de la EVM de menor coste.El gas golfing suele centrarse en microoptimizaciones, en lugar de rediseñar por completo la aplicación.Por tanto, es más limitado que la optimización general del gas, que puede incluir la arquitectura del contrato, la agrupación de transacciones, el despliegue en una solución de capa 2, el diseño de la aplicación y el cálculo off-chain.Un cambio de gas golfing satisfactorio debe preservar la seguridad, la corrección, la legibilidad y la compatibilidad.Ahorrar una pequeña cantidad de gas no compensa si el cambio crea una vulnerabilidad o hace que el contrato sea imposible de mantener de forma segura.

¿Por qué se llama gas golfing?

La palabra «golfing» alude al objetivo de obtener una puntuación más baja.En el golf tradicional, cuanto menor es el número de golpes, mejor.En el gas golfing de contratos inteligentes, generalmente se considera mejor consumir menos gas si el código optimizado realiza la misma tarea de forma segura.Los desarrolladores pueden comparar dos implementaciones midiendo el gas de despliegue, el gas de ejecución, el tamaño del bytecode o el coste total durante la vida útil prevista del contrato.Un reto de gas golfing puede pedir a los participantes que implementen una función con el menor consumo de gas posible.El desarrollo de producción es más complejo, porque la solución que consume menos gas puede no ser la más segura o la más fácil de auditar.El término es informal y no describe un protocolo, token, tipo de transacción ni estándar de programación oficial de Ethereum.

Cómo funciona el gas golfing

Ethereum asigna un coste de gas a cada operación que realiza la Ethereum Virtual Machine.

La documentación oficial de Ethereum sobre el gas explica que el gas mide el esfuerzo computacional necesario para ejecutar transacciones y operaciones de contratos inteligentes.

La aritmética, el uso de memoria, el almacenamiento persistente, los registros de eventos, las llamadas a contratos, la creación de contratos y los datos de transacción contribuyen al consumo de gas.El gas golfing busca una secuencia de operaciones menos costosa que produzca el mismo resultado requerido.Por ejemplo, un desarrollador puede sustituir varias lecturas de almacenamiento por una sola y reutilizar el valor cargado en una variable local.Otro desarrollador puede reemplazar una cadena de reversión larga por un error personalizado compacto.Un desarrollador que trabaje a bajo nivel puede sustituir un bucle manual de copia de memoria por una instrucción de la EVM diseñada específicamente para esa tarea.La mejora final debe medirse en el bytecode compilado, porque un código Solidity visualmente más corto no siempre se traduce en una ejecución de la EVM más barata.

Gas golfing frente a optimización del gas

La optimización del gas es el proceso general de reducir el coste de desplegar y ejecutar contratos inteligentes.El gas golfing es una forma más limitada de optimización que suele centrarse en pequeños ahorros a nivel de código.Un proyecto completo de optimización del gas puede rediseñar el modelo de almacenamiento de la aplicación, trasladar cálculos adecuados off-chain, utilizar una red de capa 2 o reducir el número de transacciones que necesita cada usuario.En cambio, el gas golfing puede comparar dos estructuras de bucle, dos métodos de gestión de errores o dos formas de cargar el mismo valor.La optimización arquitectónica suele generar ahorros mayores que la microoptimización.Sin embargo, un pequeño ahorro recurrente puede ser importante si una función se ejecuta millones de veces.Los desarrolladores profesionales deberían eliminar primero el trabajo innecesario a nivel de arquitectura y después optimizar con gas golfing las rutas de ejecución importantes que queden.

Gas golfing frente a code golf

El code golf intenta reducir la longitud del código fuente, a menudo sin dar prioridad a la legibilidad ni al mantenimiento a largo plazo.El gas golfing intenta reducir el coste de ejecución en la blockchain.La expresión Solidity más corta puede compilarse en más instrucciones que otra más larga y clara.La optimización del compilador también puede transformar varios estilos de código fuente en un bytecode idéntico.Por tanto, los desarrolladores deben comparar el resultado compilado y el gas medido, en lugar de contar caracteres del código fuente.Una solución de code golf puede resultar entretenida, pero no ser adecuada para un contrato que controla criptomonedas de valor.El gas golfing en producción siempre debe incluir pruebas de seguridad, documentación y revisión.

Gas golfing frente a precios más bajos del gas

El gas golfing reduce el número de unidades de gas que consume una transacción.No reduce directamente el precio de mercado que se paga por cada unidad de gas.La comisión de transacción puede expresarse como Gas Charged × Effective Gas Price.Un cambio de gas golfing reduce la parte correspondiente a Gas Charged de esta fórmula.La demanda de la red, la comisión base del protocolo y la comisión de prioridad del usuario afectan al Effective Gas Price.Un contrato puede estar muy optimizado y seguir siendo caro de utilizar durante una congestión grave de la red.Un contrato mal optimizado también puede seguir siendo ineficiente aunque el precio del gas sea temporalmente bajo.

Por qué los desarrolladores practican gas golfing

El gas golfing puede reducir el coste que paga cada usuario que interactúa con una función de contrato inteligente utilizada con frecuencia.Unas comisiones de transacción más bajas pueden facilitar el acceso a las finanzas descentralizadas, las transferencias de tokens, los juegos blockchain, las operaciones con NFT y los sistemas de gobernanza.El gas golfing también puede reducir el coste de desplegar un contrato si la optimización disminuye el trabajo de inicialización o el tamaño del bytecode de ejecución.Las estrategias automatizadas de criptomonedas pueden depender de pequeños ahorros de gas, ya que las comisiones de transacción reducen directamente su rentabilidad esperada.Los protocolos que realizan muchas operaciones internas repetidas pueden ahorrar cantidades considerables, aunque cada mejora individual sea pequeña.Un menor consumo de gas también deja más capacidad de bloque disponible para otras transacciones.Sin embargo, la optimización debe basarse en el uso previsto, no en el deseo de obtener el resultado más bajo posible en una prueba poco realista.

Mide antes de optimizar el gas

Los desarrolladores deben medir el consumo de gas antes de intentar una microoptimización.Es posible que el compilador actual ya elimine la operación que parece innecesaria.Un cambio que reducía el gas en una versión anterior de Solidity puede no aportar ningún beneficio con un compilador actual.Otro cambio puede reducir el gas de ejecución y, al mismo tiempo, aumentar el coste de despliegue del contrato.Las pruebas de gas deben cubrir las funciones que los usuarios ejecutan con mayor frecuencia.También deben incluir entradas mínimas, entradas máximas admitidas, ejecuciones satisfactorias y rutas de error.

La documentación del compilador de Solidity describe las opciones de salida del compilador y las estimaciones de gas.

Las estimaciones del compilador pueden ser incompletas cuando los bucles, las llamadas externas o el estado dinámico de la blockchain afectan a la ejecución.Por tanto, los desarrolladores deben combinar los resultados del compilador con pruebas de transacciones reales y trazas de ejecución.

Utiliza un compilador Solidity actualizado

Las versiones del compilador Solidity incorporan periódicamente optimizaciones, compatibilidad con la EVM, funciones del lenguaje y correcciones de seguridad.

El anuncio oficial de la versión Solidity 0.8.36 indica que la versión 0.8.36 es la actual en julio de 2026.

Esta versión incluye correcciones de seguridad y avances adicionales en una canalización experimental de generación de código en formato SSA.El resultado de una optimización de gas obtenido con una versión del compilador puede diferir del que se obtiene con otra.Los desarrolladores deben fijar la versión del compilador, la configuración del optimizador, el destino de la EVM y las versiones de las dependencias utilizadas para las compilaciones de producción.

Antes de desplegar contratos que controlen criptomonedas de valor, también deben revisar la lista oficial de errores del compilador Solidity.

Actualizar el compilador únicamente para reducir el consumo de gas, sin volver a probar toda la aplicación, puede introducir comportamientos inesperados o diferencias en el bytecode.

Utiliza el optimizador de Solidity antes de optimizar manualmente

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

La documentación oficial del optimizador de Solidity explica que la optimización puede reducir tanto el tamaño del despliegue como el coste de ejecución.

La optimización manual del gas debe tener en cuenta lo que ya hace el optimizador.Dos funciones Solidity visiblemente distintas pueden compilarse en el mismo bytecode optimizado.El parámetro runs del optimizador influye en el equilibrio entre un código de despliegue más pequeño y unos costes de ejecución recurrente más bajos.Un valor bajo de runs suele dar más importancia al tamaño del despliegue.Un valor alto de runs suele dar más importancia a la ejecución recurrente.La configuración más adecuada depende de la frecuencia con la que se desplegará el contrato y se llamará a cada función.Los desarrolladores deben comparar varias configuraciones probadas, en vez de elegir un valor tradicional sin medirlo.

Almacena en caché las lecturas repetidas de almacenamiento

El acceso al almacenamiento persistente suele ser más caro que utilizar un valor ya disponible en la pila de la EVM o en la memoria.Una técnica habitual de gas golfing consiste en cargar una vez un valor de almacenamiento en una variable local y reutilizarlo.

Ethereum aplica costes de acceso cold y warm conforme a EIP-2929.

El primer acceso a una posición de almacenamiento en una transacción suele ser más caro que los accesos posteriores a esa misma posición.Incluso se pueden evitar lecturas de almacenamiento warm si el contrato ya dispone de una copia local correcta.Un desarrollador también puede calcular localmente el resultado final y realizar una sola escritura de almacenamiento, en lugar de escribir cada valor intermedio.El almacenamiento en caché no es seguro si una llamada externa puede modificar el estado pertinente antes de que se vuelva a utilizar el valor guardado.Antes de aplicar esta técnica, deben tenerse en cuenta la reentrada, las devoluciones de llamada, las llamadas delegate y el comportamiento heredado.

Reduce las escrituras de almacenamiento

Escribir en el estado persistente es una de las operaciones habituales más caras de los contratos inteligentes.Un contrato debe evitar escribir un valor cuando el valor solicitado ya está almacenado.También debe evitar registrar información que pueda derivarse de forma segura del estado existente.En algunos casos, varios valores relacionados pueden representarse mediante un único índice acumulado o punto de control contable.Una función también puede realizar cálculos localmente y guardar solo el resultado final en el almacenamiento.Estos cambios pueden generar ahorros mucho mayores que reescribir una pequeña expresión aritmética.Los desarrolladores deben confirmar que el modelo de estado simplificado sigue admitiendo saldos, permisos, contabilidad histórica y actualizaciones correctos.

Agrupa las variables de almacenamiento

Ethereum divide el almacenamiento de los contratos en posiciones de 32 bytes.Solidity puede agrupar varias variables de tipos de valor más pequeños en una sola posición si el orden y el tamaño combinado lo permiten.

La documentación de Solidity sobre la disposición del almacenamiento explica cómo se asignan y agrupan las variables.

Reducir el número de posiciones de almacenamiento necesarias puede disminuir el gas de despliegue y de ejecución en determinados casos.Los tipos enteros más pequeños no ahorran gas automáticamente cuando se almacenan por separado.La EVM suele realizar operaciones aritméticas con palabras de 256 bits, por lo que los tipos más pequeños pueden requerir máscaras o conversiones adicionales.La agrupación resulta más útil cuando los valores agrupados se consultan o modifican habitualmente en conjunto.Las variables de almacenamiento no deben reordenarse en un contrato actualizable ya desplegado, porque la nueva disposición podría interpretar incorrectamente los datos existentes.

Utiliza valores constantes e inmutables

Una variable de estado normal genera costes de almacenamiento cuando es necesario leer su valor del estado persistente.

Un valor conocido en tiempo de compilación puede declararse

.

Un valor seleccionado durante la construcción y que no cambia tras el despliegue puede declararse

.

La documentación de Solidity sobre contratos explica que estos valores no utilizan posiciones de almacenamiento ordinarias del mismo modo que las variables de estado modificables.

Las direcciones permanentes, los valores matemáticos y los límites de configuración fijos son opciones habituales.Un valor no debe declararse immutable si la aplicación necesita realmente un proceso autorizado para actualizarlo.Ahorrar gas eliminando una flexibilidad de configuración necesaria puede crear una limitación operativa costosa o peligrosa.

Utiliza calldata para las entradas de solo lectura

Las entradas de funciones externas que no necesitan modificarse pueden permanecer a menudo en

.

El uso de calldata puede evitar copiar una cadena, secuencia de bytes, matriz o struct de gran tamaño a la memoria.

La documentación de Solidity sobre la ubicación de datos explica las diferencias entre calldata, memory, storage y almacenamiento transitorio.

Esta técnica resulta más útil para entradas externas dinámicas que la función solo necesita leer.La memoria sigue siendo necesaria cuando el contrato debe modificar el valor o crear nuevos datos en memoria.Los desarrolladores también deben eliminar los datos de entrada de transacción innecesarios, ya que los bytes de calldata contribuyen al coste de gas intrínseco.Codificar un valor de forma más compacta puede ahorrar gas de calldata, pero la comparación debe incluir el cálculo necesario para decodificarlo.

Utiliza errores personalizados

Los errores personalizados pueden reducir el bytecode del contrato y el coste de los datos de reversión en comparación con las cadenas de error largas.Un error personalizado utiliza un selector compacto de cuatro bytes y puede incluir parámetros estructurados.

La documentación oficial de Solidity sobre errores personalizados los describe como un método eficiente en cuanto a gas para informar de errores.

Por ejemplo, un error puede incluir la dirección del remitente y el saldo requerido, sin incorporar una frase larga al bytecode de ejecución.Un error personalizado no hace que la ruta de ejecución satisfactoria sea gratuita, ya que el contrato sigue teniendo que evaluar la condición.Los errores deben ser lo bastante claros para que las wallets, las interfaces, los auditores y los desarrolladores puedan diagnosticar transacciones de criptomonedas fallidas.

Ordena las condiciones para aprovechar la evaluación de cortocircuito

Las expresiones booleanas de Solidity pueden detenerse antes cuando el resultado final ya se conoce.En una expresión con AND lógico, la evaluación puede detenerse tras la primera condición falsa.En una expresión con OR lógico, puede detenerse tras la primera condición verdadera.Colocar una condición barata antes que una costosa puede reducir el gas medio si la condición barata suele determinar el resultado.Esta técnica debe preservar el comportamiento lógico previsto y las suposiciones sobre funciones que pueden revertir o tener efectos secundarios.Las condiciones no deben reordenarse sin más cuando el orden sea relevante para la seguridad o la comunicación de errores.

Optimiza los bucles con cuidado

Un bucle puede consumir mucho gas cuando procesa numerosos elementos.Los desarrolladores pueden almacenar en caché la longitud de una matriz a la que se accede repetidamente si la colección no puede cambiar durante el bucle.También pueden guardar en caché los valores de almacenamiento utilizados en cada iteración.

El contador de un bucle puede utilizar un incremento

cuando sea matemáticamente imposible que se desborde.

Los compiladores modernos ya optimizan algunos patrones de incremento habituales, por lo que el ahorro debe medirse con el compilador elegido.La afirmación habitual de que el incremento prefijo siempre es más barato que el incremento posfijo no es una regla universal fiable para el código Solidity optimizado actual.Un bucle sin límite sobre una colección de almacenamiento creciente es un problema arquitectónico, no una pequeña oportunidad de gas golfing.Las cargas de trabajo grandes deben dividirse en lotes limitados o rediseñarse para que los usuarios procesen sus propios estados independientes.

Utiliza aritmética unchecked solo si puedes demostrar que es segura

Solidity 0.8 y versiones posteriores comprueban normalmente los desbordamientos y subdesbordamientos de la aritmética de enteros.Estas comprobaciones consumen algo de gas, pero evitan categorías importantes de errores de programación.

Un bloque

elimina la comprobación automática de las operaciones que contiene.

Esto puede ahorrar gas cuando los límites matemáticos demuestran que no puede producirse un desbordamiento.Un contador de bucle limitado es un ejemplo habitual, aunque el argumento concreto de seguridad depende del diseño del bucle.No debe utilizarse aritmética unchecked simplemente porque normalmente se espera que la entrada sea pequeña.El código debe incluir pruebas y documentación clara que demuestren por qué todas las entradas posibles son seguras.

Utiliza almacenamiento transitorio para el estado temporal

El almacenamiento transitorio proporciona un estado limitado a la transacción, que se borra automáticamente cuando esta termina.

Ethereum introdujo las operaciones

y mediante EIP-1153.

El almacenamiento transitorio puede ser más barato que el persistente cuando los datos se necesitan entre llamadas, pero no entre transacciones.Un bloqueo de reentrada es un ejemplo habitual de información limitada a una transacción.El almacenamiento transitorio no puede sustituir saldos, titularidad, deuda o configuración persistentes que se necesiten en transacciones posteriores.Los desarrolladores deben comprender cómo se comporta el estado transitorio entre llamadas, llamadas delegate y reversiones.Sustituir un control de seguridad probado por una implementación transitoria de menor coste requiere pruebas y revisión completas.

Utiliza instrucciones modernas de la EVM

Las actualizaciones de Ethereum pueden introducir instrucciones que sustituyen secuencias más costosas de operaciones anteriores.

EIP-3855 introdujo

, que coloca un cero en la pila mediante una instrucción compacta.

EIP-5656 introdujo

, que proporciona una operación específica para copiar memoria.

Un compilador Solidity actualizado puede utilizar automáticamente las instrucciones de la EVM admitidas si se selecciona la versión correcta de la EVM.Por lo general, los desarrolladores no deberían sustituir código generado por el compilador por ensamblador escrito a mano solo para forzar una instrucción.Un contrato compilado para un destino EVM nuevo puede fallar en una red que aún no haya activado las instrucciones necesarias.Por tanto, los resultados del gas golfing deben indicar exactamente qué compilador y destino EVM se utilizaron para la medición.

Reduce las llamadas externas

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 puede ahorrar gas evitando llamadas repetidas que devuelven el mismo valor durante una transacción.En ocasiones, varias lecturas relacionadas pueden combinarse en una sola llamada que devuelva un resultado estructurado.Sin embargo, cambiar la estructura de las llamadas puede afectar a la reentrada, la gestión de errores, la componibilidad y los límites entre contratos.Los valores devueltos y las condiciones de éxito deben seguir comprobándose correctamente.Una llamada barata que genere una suposición insegura no es una optimización válida.

Utiliza eventos en lugar de almacenamiento cuando proceda

Los registros de eventos suelen ser menos costosos que el almacenamiento persistente para información que solo utilizan aplicaciones off-chain.Los eventos pueden utilizarse para historiales de transacciones, análisis, feeds de actividad y notificaciones de interfaz.Por lo general, la ejecución futura de contratos inteligentes no puede buscar en los registros históricos de eventos.Por tanto, los saldos, permisos, titularidad, garantías y otros estados exigibles deben seguir siendo accesibles para el contrato.El gas golfing con eventos solo es adecuado cuando el valor de almacenamiento eliminado no se necesita para futuras decisiones on-chain.Al diseñar el evento, los desarrolladores también deben tener en cuenta el coste de los temas de evento indexados y los datos del registro.

Reduce el bytecode de despliegue

Ethereum cobra gas cuando se almacena el bytecode de ejecución de un contrato durante el despliegue.Eliminar funciones sin uso, lógica duplicada, cadenas de reversión largas y datos integrados innecesarios puede reducir el coste de despliegue.Los errores personalizados, las bibliotecas internas, las implementaciones compartidas y una configuración cuidadosa de la optimización del compilador pueden reducir el tamaño del código.

Ethereum limita el código de ejecución desplegado normal mediante EIP-170.

El código de inicialización tiene límites y medición independientes conforme a EIP-3860.

Un contrato más pequeño no es automáticamente más barato durante toda su vida útil, porque dividir el código entre varios contratos puede añadir costes repetidos de llamadas externas.Los desarrolladores deben evaluar conjuntamente el coste de despliegue y el de ejecución recurrente.

Comprende las limitaciones de las devoluciones de gas

Algunas estrategias antiguas de gas golfing en Ethereum dependían en gran medida de crear y borrar posteriormente almacenamiento.Las reglas actuales de Ethereum limitan mucho este método.

EIP-3529 redujo las devoluciones por borrar almacenamiento, eliminó la antigua devolución de

y limitó las devoluciones aplicadas al 20% del uso bruto de gas.

Un contrato no debería crear estado innecesario con la esperanza de recibir una devolución igual o superior más adelante.Las devoluciones de gas se aplican después de la ejecución y no pueden evitar un error por falta de gas.

tampoco es una técnica moderna de gas golfing, ya que no ofrece ninguna devolución y su comportamiento de eliminación está restringido.

Optimización de calldata y EIP-7623

En ocasiones, los desarrolladores optimizan con gas golfing los datos de entrada de las transacciones utilizando tipos compactos, empaquetado de bits, codificaciones personalizadas o representaciones más cortas.Reducir los bytes de una transacción puede disminuir el gas intrínseco, especialmente si se eliminan muchos valores repetidos.

Sin embargo, Pectra activó EIP-7623, que introdujo un límite mínimo de gas más alto para transacciones con muchos datos y relativamente poca ejecución.

Las operaciones de decodificación necesarias para un formato compacto también consumen gas.Una codificación personalizada puede reducir el coste de cargas de trabajo grandes y repetidas, pero no aportar ningún beneficio en transacciones pequeñas.Una codificación no estándar puede dificultar el uso de wallets, las auditorías, las integraciones y la depuración.Los desarrolladores deben probar todo el proceso de codificación y decodificación conforme a las reglas actuales del protocolo.

Cuándo es apropiado el ensamblador en línea

El ensamblador en línea permite a los desarrolladores controlar directamente las instrucciones de la EVM, la memoria, el almacenamiento, las llamadas y los datos devueltos.Puede ahorrar gas cuando Solidity de alto nivel no permite expresar una operación especializada de forma eficiente.El ensamblador suele considerarse para rutinas criptográficas, análisis de datos compactos, operaciones de memoria poco habituales y funciones de bajo nivel que se repiten mucho.También omite muchas de las protecciones de tipos, memoria y seguridad que proporciona Solidity.Un error de ensamblador puede corromper la memoria, codificar datos incorrectamente, gestionar mal los valores devueltos o exponer criptomonedas al robo.Toda implementación en ensamblador debe compararse con una implementación de referencia clara de alto nivel.Las pruebas deben confirmar que el comportamiento es idéntico con entradas normales, límites, entradas maliciosas y reversiones.

Cuándo se vuelve peligroso el gas golfing

El gas golfing se vuelve peligroso cuando se da más prioridad al coste de gas que a la seguridad y la claridad del contrato.Eliminar comprobaciones de control de acceso para ahorrar gas puede permitir que usuarios no autorizados controlen el contrato.Eliminar una protección contra reentrada puede exponer los saldos a llamadas externas repetidas.Eliminar límites de deslizamiento o plazos puede exponer a los usuarios a ejecuciones desfavorables de criptomonedas.Combinar muchos valores en una sola palabra empaquetada puede introducir errores de máscaras de bits y conversiones.Sustituir la codificación estándar por un formato personalizado puede crear vulnerabilidades de firma, repetición o análisis de datos.Una optimización que ahorra 100 unidades de gas, pero crea la posibilidad de perder fondos de usuarios, tiene un valor práctico negativo.

Consejos de gas golfing desactualizados

Los consejos de gas golfing pueden quedar obsoletos cuando cambian Solidity y la EVM.Un compilador puede empezar a optimizar un patrón que antes requería una reescritura manual.Una actualización de la red puede cambiar el precio de un opcode o añadir una instrucción más eficiente.

La antigua recomendación de utilizar

para obtener devoluciones ya no es válida en el Ethereum actual.

La afirmación de que un estilo de incremento siempre es más barato puede no aplicarse al bytecode optimizado moderno.Una recomendación de utilizar un entero muy pequeño puede no ahorrar gas si no se agrupa con otras variables en el almacenamiento.Antes de adoptar cualquier consejo de gas golfing, los desarrolladores deben exigir pruebas comparativas actuales y una configuración reproducible del compilador.

Cómo evaluar un cambio de gas golfing

En primer lugar, la implementación optimizada debe producir el mismo comportamiento requerido que la original.Los desarrolladores deben comparar el gas de despliegue, el gas de ejecución satisfactoria, el gas de las rutas de error y el coste total previsto durante la vida útil.Deben identificar el compilador, la configuración del optimizador, la versión de la EVM y el estado de la blockchain utilizados en las pruebas.Las pruebas unitarias deben verificar el comportamiento normal de las funciones.Las pruebas fuzz deben explorar entradas inesperadas y condiciones límite.Las pruebas de invariantes deben confirmar que se mantienen las propiedades contables y de seguridad esenciales.Las trazas de ejecución deben confirmar que el ahorro procede de las operaciones previstas y no de haber omitido accidentalmente un requisito.Los revisores humanos deben determinar si el cambio sigue siendo comprensible y mantenible.

Gas golfing en contratos de producción

El gas golfing en producción debe centrarse en funciones utilizadas con frecuencia y cuellos de botella medidos correctamente.Un ahorro menor en una función ejecutada millones de veces puede justificar un trabajo de implementación cuidadoso.Un ahorro similar en una función administrativa que se ejecuta una sola vez quizá no justifique una mayor complejidad.Las interfaces públicas y el comportamiento previsto deben seguir siendo estables, salvo que la optimización forme parte de una actualización planificada del protocolo.Los contratos actualizables deben preservar la disposición del almacenamiento y el modelo de autorización.Los contratos de gran valor deben someterse a una revisión de seguridad independiente tras una optimización sustancial de bajo nivel.El bytecode desplegado debe poder reproducirse a partir del código fuente publicado y la configuración de compilación.

Errores habituales de gas golfing

Un error habitual es comparar la longitud del código fuente en lugar del consumo de gas del código compilado.Otro error es hacer pruebas sin activar la misma configuración del optimizador que se utilizará en producción.Los desarrolladores pueden medir solo las transacciones satisfactorias e ignorar una ruta de reversión inusualmente costosa.También pueden optimizar una función que apenas se utiliza e ignorar una escritura de almacenamiento repetida en cada transacción.Pueden usar tipos enteros más pequeños sin obtener ninguna ventaja de agrupación en el almacenamiento.Pueden sustituir Solidity claro por ensamblador sin confirmar antes que el código generado por el compilador sea realmente costoso.Pueden basarse en un calendario de gas antiguo que ya no refleja la EVM actual.El error más grave es aceptar un menor consumo de gas sin demostrar que la versión optimizada mantiene un comportamiento seguro e idéntico.

Preguntas frecuentes

¿Qué es el gas golfing explicado de forma sencilla?

El gas golfing consiste en realizar pequeños cambios a nivel de código para reducir el gas que consume un contrato inteligente sin alterar su comportamiento previsto.

¿Es lo mismo el gas golfing que la optimización del gas?

No. El gas golfing suele ser una forma limitada de microoptimización, mientras que la optimización del gas también incluye la arquitectura, el diseño del almacenamiento, el cálculo off-chain, la agrupación de operaciones y la elección de la red.

¿Es el gas golfing una función del protocolo Ethereum?

No. Es un término informal de los desarrolladores, no un opcode, tipo de transacción o estándar oficial de Ethereum.

¿El código Solidity más corto siempre consume menos gas?

No. La longitud del código fuente no permite predecir de forma fiable el tamaño o el coste de ejecución del bytecode compilado de la EVM.

¿El optimizador de Solidity puede realizar gas golfing automáticamente?

El optimizador realiza muchas transformaciones similares, pero los desarrolladores siguen teniendo que diseñar de forma eficiente el almacenamiento, el flujo de datos y la arquitectura del contrato.

¿Cuál es la mejor técnica de gas golfing?

La técnica más valiosa depende a menudo del contrato, aunque reducir el acceso repetido al almacenamiento suele aportar más que modificar expresiones aritméticas menores.

¿Los enteros más pequeños siempre son más baratos?

No. Son más útiles cuando permiten que varios valores compartan una posición de almacenamiento.

¿Calldata siempre es más barata que memory?

Calldata suele ser más barata para las entradas externas de solo lectura porque evita una copia, pero la ubicación adecuada depende de cómo deban utilizarse los datos.

¿Por qué son útiles los errores personalizados para el gas golfing?

Los errores personalizados utilizan selectores y parámetros compactos en lugar de incorporar y devolver cadenas de reversión largas.

¿Almacenar en caché un valor de almacenamiento siempre ahorra gas?

Puede ahorrar gas si el valor sigue siendo válido, pero el almacenamiento en caché puede ser inseguro si una llamada externa puede cambiar el estado.

¿La aritmética unchecked es una optimización segura?

Solo es segura cuando los desarrolladores pueden demostrar que no es posible un desbordamiento o subdesbordamiento con ninguna entrada alcanzable.

¿Deberían utilizar ensamblador en línea quienes optimizan el gas?

El ensamblador en línea debe limitarse a cuellos de botella medidos, ya que puede introducir errores graves de memoria, codificación y seguridad.

¿El incremento prefijo siempre cuesta menos que el incremento posfijo?

No. La optimización actual del compilador puede generar código equivalente, por lo que hay que medir el resultado concreto.

¿Pueden los eventos sustituir al almacenamiento de contratos?

Los eventos solo pueden sustituir al almacenamiento para información que la ejecución futura de contratos inteligentes no necesite leer ni exigir.

¿El gas golfing puede hacer que una transacción sea gratuita?

No. Todas las transacciones siguen pagando por la ejecución, los datos y el uso del estado necesarios, conforme a las reglas de comisiones de la red.

¿El gas golfing reduce el precio del gas?

No. Reduce el consumo de gas, mientras que el precio del gas cambia según la demanda de la red y la configuración de las comisiones de la transacción.

¿Las devoluciones de gas son un método de gas golfing?

La eliminación de almacenamiento que cumpla los requisitos puede ofrecer una devolución limitada, pero las reglas actuales limitan las devoluciones y ya no permiten las antiguas estrategias basadas en devoluciones elevadas.

¿El gas golfing puede generar riesgos de seguridad?

Sí. La compresión agresiva, la aritmética unchecked, el ensamblador y la eliminación de validaciones pueden crear vulnerabilidades si no se revisan cuidadosamente.

¿Cómo deben probarse los resultados del gas golfing?

Deben probarse con una configuración fija del compilador, entradas realistas, trazas de ejecución, pruebas fuzz, invariantes y una revisión de seguridad.

¿Cuándo merece la pena el gas golfing?

Merece más la pena cuando un cambio seguro reduce el coste de una función que los usuarios o los sistemas automatizados ejecutan con frecuencia.

Conclusión

El gas golfing consiste en realizar cambios específicos en contratos inteligentes para reducir el gas de despliegue o ejecución.Está relacionado con la optimización del gas, pero suele centrarse en mejoras más pequeñas a nivel de código, en lugar de rediseñar por completo la aplicación.Entre los métodos habituales de gas golfing están almacenar en caché las lecturas de almacenamiento, reducir las escrituras, agrupar variables, utilizar calldata, elegir errores personalizados, simplificar bucles y aprovechar funciones modernas de la EVM.El efecto de cada método depende de la versión del compilador, la configuración del optimizador, el destino de la EVM, los valores de entrada y el estado de la blockchain.Los consejos que generaban ahorros en un entorno antiguo de Ethereum pueden no funcionar con las reglas actuales del compilador y del protocolo.Los desarrolladores deben medir el bytecode compilado, en lugar de juzgar la eficiencia por el aspecto o la longitud del código fuente Solidity.Por lo general, deben considerarse las mejoras arquitectónicas antes que la microoptimización de bajo nivel.El ensamblador en línea y las operaciones unchecked deben limitarse a situaciones en las que sus ahorros puedan medirse y su seguridad demostrarse.Todo cambio de gas golfing debe preservar el comportamiento, la seguridad, la legibilidad y la compatibilidad del contrato.El mejor resultado de gas golfing no consiste simplemente en obtener la cifra de gas más baja, sino en alcanzar el menor coste seguro para proporcionar la funcionalidad de criptomonedas requerida.