Siguiendo estas prácticas, los desarrolladores pueden reducir el consumo de Gas en contratos inteligentes, reducir los costos de transacción y crear aplicaciones más eficientes y amigables para el usuario.
Las comisiones de gas en la red principal de Ethereum siempre han sido un problema importante, especialmente durante períodos de congestión de la red. Durante los momentos de mayor demanda, los usuarios a menudo necesitan pagar tarifas de transacción extremadamente altas. Por lo tanto, optimizar los costos de gas durante la fase de desarrollo de contratos inteligentes es crucial. La optimización del gas no solo puede reducir eficazmente los costos de transacción, sino también mejorar la eficiencia de las transacciones, brindando a los usuarios una experiencia blockchain más económica y eficiente.
Este artículo describirá el mecanismo de tarifas de gas de la Máquina Virtual Ethereum (EVM), los conceptos principales relacionados con la optimización de tarifas de gas y las mejores prácticas para optimizar las tarifas de gas al desarrollar contratos inteligentes. Se espera que este contenido inspire y ayude a los desarrolladores, al tiempo que ayuda a los usuarios comunes a comprender mejor cómo funciona el sistema de tarifas de gas de EVM, abordando juntos los desafíos dentro del ecosistema blockchain.
En redes compatibles con EVM, 'Gas' se refiere a la unidad utilizada para medir la potencia computacional requerida para ejecutar operaciones específicas.
El diagrama a continuación ilustra la estructura del EVM. En el diagrama, el consumo de Gas se divide en tres partes: ejecución de operaciones, llamadas de mensajes externos y lectura/escritura de memoria y almacenamiento.
Fuente: Sitio web oficial de Ethereum[1]
Desde la activación de EIP-1559 (London Hard Fork), las tarifas de gas se calculan utilizando la siguiente fórmula:
Tarifa de gas = unidades de gas utilizadas * (tarifa base + tarifa de prioridad)
La tarifa base se quema, mientras que la tarifa de prioridad sirve como incentivo para animar a los validadores a incluir la transacción en la cadena de bloques. Establecer una tarifa de prioridad más alta al enviar una transacción aumenta la probabilidad de que la transacción se incluya en el próximo bloque. Esto es similar a una "propina" que los usuarios pagan a los validadores.
Al compilar un contrato inteligente con Solidity, el contrato se convierte en una serie de "códigos de operación", u opcodes.
Cada opcode (como crear un contrato, hacer llamadas de mensajes, acceder al almacenamiento de cuentas y ejecutar operaciones en la máquina virtual) tiene un costo asociado de consumo de Gas, que está documentado en el Libro Amarillo de Ethereum[2].
Después de múltiples modificaciones de EIP, los costos de Gas de algunos códigos de operación se han ajustado, lo que puede diferir de los valores en el Libro Amarillo. Para obtener información detallada sobre los últimos costos de códigos de operación, consulte esta fuente[3].
El concepto central de optimización de Gas es priorizar operaciones rentables en la cadena de bloques EVM y evitar operaciones que generen altos costos de Gas.
En el EVM, las siguientes operaciones son relativamente económicas:
Las operaciones de alto costo incluyen:
Basándonos en los conceptos básicos anteriores, hemos compilado una lista de las mejores prácticas de optimización de tarifas de gas para la comunidad de desarrolladores. Al seguir estas prácticas, los desarrolladores pueden reducir el consumo de gas de los contratos inteligentes, disminuir los costos de transacción y crear aplicaciones más eficientes y amigables para el usuario.
En Solidity, el almacenamiento es un recurso limitado, y su consumo de gas es significativamente mayor que la memoria. Cada vez que un contrato inteligente lee o escribe en el almacenamiento, incurre en un alto costo de gas.
Según la definición en el Libro Amarillo de Ethereum, el costo de las operaciones de almacenamiento es más de 100 veces mayor que las operaciones de memoria. Por ejemplo, los opcodes como sload y sstore cuestan al menos 100 unidades de Gas en el mejor de los casos, mientras que las operaciones de memoria como mload y mstore solo consumen 3 unidades de Gas.
Métodos para limitar el uso de almacenamiento incluyen:
El número de ranuras de almacenamiento utilizadas en un contrato inteligente y cómo los desarrolladores representan los datos pueden afectar significativamente el consumo de Gas.
El compilador de Solidity empaqueta variables de almacenamiento consecutivas durante el proceso de compilación, utilizando ranuras de almacenamiento de 32 bytes como unidad básica para el almacenamiento de variables. El empaquetado de variables se refiere a la práctica de organizar variables de manera que varias variables puedan caber en una sola ranura de almacenamiento.
A la izquierda hay una implementación menos eficiente que consume 3 espacios de almacenamiento; a la derecha hay una implementación más eficiente.
Al realizar este ajuste, los desarrolladores pueden ahorrar 20,000 unidades de gas (ya que almacenar una ranura de almacenamiento no utilizada cuesta 20,000 unidades de gas), pero ahora solo se requieren dos ranuras de almacenamiento.
Dado que cada espacio de almacenamiento consume gas, el empaquetado de variables optimiza el uso de gas al reducir el número de espacios de almacenamiento requeridos.
Una variable puede representarse utilizando diferentes tipos de datos, pero los costos de operación varían según el tipo. Elegir el tipo de dato adecuado ayuda a optimizar el uso de Gas.
Por ejemplo, en Solidity, los enteros se pueden subdividir en diferentes tamaños: uint8, uint16, uint32, etc. Dado que la EVM opera en unidades de 256 bits, usar uint8 significa que la EVM primero debe convertirlo a uint256, y esta conversión conlleva costos adicionales de gas.
Podemos comparar los costos de gas de uint8 y uint256 utilizando el código en el diagrama. La función UseUint () consume 120,382 unidades de gas, mientras que la función UseUInt8 () consume 166,111 unidades de gas.
Por sí solo, el uso de uint256 es más barato que uint8. Sin embargo, si aplicamos la optimización de empaquetado de variables previamente sugerida, marca la diferencia. Si los desarrolladores pueden empaquetar cuatro variables uint8 en una única ranura de almacenamiento, el costo total de iterar sobre ellas será menor que usar cuatro variables uint256. En este caso, el contrato inteligente puede leer y escribir la ranura de almacenamiento una vez, y cargar las cuatro variables uint8 en la memoria/almacenamiento en una sola operación.
Si los datos pueden ser limitados a 32 bytes, se recomienda usar el tipo de dato bytes32 en lugar de bytes o cadenas de texto. En general, las variables de tamaño fijo consumen menos gas que las variables de tamaño dinámico. Si la longitud en bytes puede ser limitada, intenta elegir la longitud más pequeña, desde bytes1 hasta bytes32.
En Solidity, las listas de datos se pueden representar utilizando dos tipos de datos: Arrays y Mappings, cada uno con una sintaxis y estructura distintas.
Las asignaciones son generalmente más eficientes y rentables en la mayoría de los casos, mientras que los arrays son iterables y admiten el empaquetado de tipos de datos. Por lo tanto, se recomienda priorizar el uso de asignaciones al administrar listas de datos, a menos que se requiera iteración o se pueda optimizar el consumo de Gas mediante el empaquetado de tipos de datos.
Las variables declaradas en los parámetros de la función se pueden almacenar tanto en calldata como en memoria. La diferencia principal es que la memoria puede ser modificada por la función, mientras que calldata es inmutable.
Ten en cuenta este principio: si los parámetros de la función son de solo lectura, es preferible usar calldata en lugar de memory. Esto evita operaciones de copia innecesarias de calldata de función a memory.
Ejemplo 1: Usando la memoria
Cuando se utiliza la palabra clave de memoria, los valores del array se copian de calldata codificado a memoria durante la decodificación de ABI. El costo de ejecución de este bloque de código es de 3,694 unidades de gas.
Ejemplo 2: Usando calldata
Cuando se leen valores directamente desde calldata, se salta la operación de memoria intermedia. Esta optimización reduce el costo de ejecución a solo 2,413 unidades de Gas, lo que resulta en una mejora del 35% en la eficiencia de Gas.
Las variables constantes/inmutables no se almacenan en el almacenamiento del contrato. Estas variables se calculan en tiempo de compilación y se almacenan en el bytecode del contrato. Por lo tanto, su costo de acceso es mucho menor en comparación con las variables de almacenamiento. Se recomienda utilizar las palabras clave Constant o Immutable siempre que sea posible.
Cuando los desarrolladores pueden estar seguros de que las operaciones aritméticas no darán como resultado un desbordamiento o subdesbordamiento, pueden usar la palabra clave sin verificar introducida en Solidity v0.8.0 para evitar comprobaciones innecesarias de desbordamiento o subdesbordamiento y, así, ahorrar costos de gas.
En el diagrama siguiente, la condición restringida i
Además, las versiones del compilador 0.8.0 y superiores ya no requieren el uso de la biblioteca SafeMath, ya que el compilador en sí ahora incluye protección incorporada contra desbordamiento y subdesbordamiento.
El código de los modificadores se incrusta en las funciones que modifican. Cada vez que se utiliza un modificador, se duplica su código, lo que aumenta el tamaño del bytecode y eleva el consumo de Gas. Aquí hay una forma de optimizar el costo de Gas de los modificadores:
Antes de la optimización:
Después de la optimización:
En este ejemplo, al refactorizar la lógica en una función interna _checkOwner(), que se puede reutilizar en el modificador, se reduce el tamaño del bytecode y se reducen los costos de Gas.
Para los operadores || (OR) y && (AND), las operaciones lógicas se evalúan con cortocircuito, lo que significa que si la primera condición es suficiente para determinar el resultado de la expresión lógica, la segunda condición no se evaluará.
Para optimizar el consumo de gas, las condiciones con menores costos de computación deben colocarse primero, de modo que los cálculos potencialmente costosos puedan omitirse.
Si hay funciones o variables no utilizadas en el contrato, se recomienda eliminarlas. Esta es la forma más directa de reducir los costos de implementación del contrato y mantener el tamaño del contrato pequeño.
Aquí hay algunas sugerencias prácticas:
Utilice los algoritmos más eficientes para los cálculos. Si el contrato utiliza directamente ciertos resultados de cálculo, se deben eliminar los cálculos redundantes. Esencialmente, se deben eliminar todos los cálculos no utilizados. En Ethereum, los desarrolladores pueden recibir recompensas de Gas liberando espacio de almacenamiento. Si una variable ya no es necesaria, se debe eliminar utilizando la palabra clave delete o estableciéndola en su valor predeterminado.
Optimización de bucle: Evite operaciones de bucle de alto costo, intente fusionar bucles y mover cálculos repetidos fuera del cuerpo del bucle.
Los contratos precompilados proporcionan funciones de biblioteca complejas como operaciones de criptografía y hash. Dado que el código no se ejecuta en el EVM sino que se ejecuta localmente en el nodo del cliente, se requiere menos gas. El uso de contratos precompilados puede ahorrar gas al reducir la carga computacional necesaria para ejecutar el contrato inteligente.
Los ejemplos de contratos precompilados incluyen el Algoritmo de Firma Digital de Curva Elíptica (ECDSA) y el algoritmo de hash SHA2-256. Al utilizar estos contratos precompilados en contratos inteligentes, los desarrolladores pueden reducir los costos de gas y mejorar la eficiencia de la aplicación.
Para obtener una lista completa de contratos precompilados compatibles con la red Ethereum, consulte este enlace [4].
El ensamblaje en línea permite a los desarrolladores escribir código de bajo nivel pero eficiente que puede ser ejecutado directamente por el EVM, sin utilizar opcodes costosos de Solidity. El ensamblaje en línea también permite un control más preciso sobre el uso de memoria y almacenamiento, reduciendo aún más los costos de gas. Además, el ensamblaje en línea puede realizar algunas operaciones complejas que son difíciles de implementar solo con Solidity, ofreciendo más flexibilidad para optimizar el consumo de gas.
Aquí hay un ejemplo de cómo usar el ensamblador en línea para ahorrar gas:
Como se muestra en el ejemplo anterior, el segundo caso, que utiliza ensamblaje en línea, tiene una eficiencia de Gas más alta en comparación con el caso estándar.
Sin embargo, el uso de ensamblaje en línea también puede introducir riesgos y propenso a errores. Por lo tanto, se debe usar con precaución y se recomienda solo para desarrolladores experimentados.
Las soluciones de Capa 2 pueden reducir la cantidad de datos que necesitan ser almacenados y calculados en la red principal de Ethereum.
Las soluciones de Capa 2 como rollups, sidechains y canales de estado descargan el procesamiento de transacciones de la cadena principal de Ethereum, lo que permite transacciones más rápidas y más baratas.
Al agrupar un gran número de transacciones juntas, estas soluciones reducen la cantidad de transacciones en cadena, lo que a su vez reduce las tarifas de gas. El uso de soluciones de Capa 2 también mejora la escalabilidad de Ethereum, permitiendo que más usuarios y aplicaciones participen en la red sin causar congestión debido a la sobrecarga.
Hay varias herramientas de optimización disponibles, como el optimizador solc, el optimizador de compilación de Truffle y el compilador de Solidity de Remix.
Estas herramientas pueden ayudar a minimizar el tamaño del bytecode, eliminar el código no utilizado y reducir la cantidad de operaciones necesarias para ejecutar contratos inteligentes. Combinado con otras bibliotecas de optimización de Gas como "solmate", los desarrolladores pueden reducir eficazmente los costos de Gas y mejorar la eficiencia de los contratos inteligentes.
Optimizar el consumo de gas es un paso importante para los desarrolladores, ya que no solo minimiza los costos de transacción, sino que también mejora la eficiencia de los contratos inteligentes en las redes compatibles con EVM. Al priorizar las operaciones de ahorro de costos, reducir el uso de almacenamiento, utilizar ensamblaje en línea y seguir otras mejores prácticas discutidas en este artículo, los desarrolladores pueden reducir eficazmente el consumo de gas de los contratos.
Sin embargo, es importante tener en cuenta que durante el proceso de optimización, los desarrolladores deben tener cuidado de evitar la introducción de vulnerabilidades de seguridad. En el proceso de optimizar el código y reducir el consumo de gas, la seguridad inherente del contrato inteligente nunca debe comprometerse.
[1] https://ethereum.org/es/developers/docs/gas/
[2]https://ethereum.github.io/yellowpaper/paper.pdf
[3] https://www.evm.codes/
[4]https://www.evm.codes/precompiled
Siguiendo estas prácticas, los desarrolladores pueden reducir el consumo de Gas en contratos inteligentes, reducir los costos de transacción y crear aplicaciones más eficientes y amigables para el usuario.
Las comisiones de gas en la red principal de Ethereum siempre han sido un problema importante, especialmente durante períodos de congestión de la red. Durante los momentos de mayor demanda, los usuarios a menudo necesitan pagar tarifas de transacción extremadamente altas. Por lo tanto, optimizar los costos de gas durante la fase de desarrollo de contratos inteligentes es crucial. La optimización del gas no solo puede reducir eficazmente los costos de transacción, sino también mejorar la eficiencia de las transacciones, brindando a los usuarios una experiencia blockchain más económica y eficiente.
Este artículo describirá el mecanismo de tarifas de gas de la Máquina Virtual Ethereum (EVM), los conceptos principales relacionados con la optimización de tarifas de gas y las mejores prácticas para optimizar las tarifas de gas al desarrollar contratos inteligentes. Se espera que este contenido inspire y ayude a los desarrolladores, al tiempo que ayuda a los usuarios comunes a comprender mejor cómo funciona el sistema de tarifas de gas de EVM, abordando juntos los desafíos dentro del ecosistema blockchain.
En redes compatibles con EVM, 'Gas' se refiere a la unidad utilizada para medir la potencia computacional requerida para ejecutar operaciones específicas.
El diagrama a continuación ilustra la estructura del EVM. En el diagrama, el consumo de Gas se divide en tres partes: ejecución de operaciones, llamadas de mensajes externos y lectura/escritura de memoria y almacenamiento.
Fuente: Sitio web oficial de Ethereum[1]
Desde la activación de EIP-1559 (London Hard Fork), las tarifas de gas se calculan utilizando la siguiente fórmula:
Tarifa de gas = unidades de gas utilizadas * (tarifa base + tarifa de prioridad)
La tarifa base se quema, mientras que la tarifa de prioridad sirve como incentivo para animar a los validadores a incluir la transacción en la cadena de bloques. Establecer una tarifa de prioridad más alta al enviar una transacción aumenta la probabilidad de que la transacción se incluya en el próximo bloque. Esto es similar a una "propina" que los usuarios pagan a los validadores.
Al compilar un contrato inteligente con Solidity, el contrato se convierte en una serie de "códigos de operación", u opcodes.
Cada opcode (como crear un contrato, hacer llamadas de mensajes, acceder al almacenamiento de cuentas y ejecutar operaciones en la máquina virtual) tiene un costo asociado de consumo de Gas, que está documentado en el Libro Amarillo de Ethereum[2].
Después de múltiples modificaciones de EIP, los costos de Gas de algunos códigos de operación se han ajustado, lo que puede diferir de los valores en el Libro Amarillo. Para obtener información detallada sobre los últimos costos de códigos de operación, consulte esta fuente[3].
El concepto central de optimización de Gas es priorizar operaciones rentables en la cadena de bloques EVM y evitar operaciones que generen altos costos de Gas.
En el EVM, las siguientes operaciones son relativamente económicas:
Las operaciones de alto costo incluyen:
Basándonos en los conceptos básicos anteriores, hemos compilado una lista de las mejores prácticas de optimización de tarifas de gas para la comunidad de desarrolladores. Al seguir estas prácticas, los desarrolladores pueden reducir el consumo de gas de los contratos inteligentes, disminuir los costos de transacción y crear aplicaciones más eficientes y amigables para el usuario.
En Solidity, el almacenamiento es un recurso limitado, y su consumo de gas es significativamente mayor que la memoria. Cada vez que un contrato inteligente lee o escribe en el almacenamiento, incurre en un alto costo de gas.
Según la definición en el Libro Amarillo de Ethereum, el costo de las operaciones de almacenamiento es más de 100 veces mayor que las operaciones de memoria. Por ejemplo, los opcodes como sload y sstore cuestan al menos 100 unidades de Gas en el mejor de los casos, mientras que las operaciones de memoria como mload y mstore solo consumen 3 unidades de Gas.
Métodos para limitar el uso de almacenamiento incluyen:
El número de ranuras de almacenamiento utilizadas en un contrato inteligente y cómo los desarrolladores representan los datos pueden afectar significativamente el consumo de Gas.
El compilador de Solidity empaqueta variables de almacenamiento consecutivas durante el proceso de compilación, utilizando ranuras de almacenamiento de 32 bytes como unidad básica para el almacenamiento de variables. El empaquetado de variables se refiere a la práctica de organizar variables de manera que varias variables puedan caber en una sola ranura de almacenamiento.
A la izquierda hay una implementación menos eficiente que consume 3 espacios de almacenamiento; a la derecha hay una implementación más eficiente.
Al realizar este ajuste, los desarrolladores pueden ahorrar 20,000 unidades de gas (ya que almacenar una ranura de almacenamiento no utilizada cuesta 20,000 unidades de gas), pero ahora solo se requieren dos ranuras de almacenamiento.
Dado que cada espacio de almacenamiento consume gas, el empaquetado de variables optimiza el uso de gas al reducir el número de espacios de almacenamiento requeridos.
Una variable puede representarse utilizando diferentes tipos de datos, pero los costos de operación varían según el tipo. Elegir el tipo de dato adecuado ayuda a optimizar el uso de Gas.
Por ejemplo, en Solidity, los enteros se pueden subdividir en diferentes tamaños: uint8, uint16, uint32, etc. Dado que la EVM opera en unidades de 256 bits, usar uint8 significa que la EVM primero debe convertirlo a uint256, y esta conversión conlleva costos adicionales de gas.
Podemos comparar los costos de gas de uint8 y uint256 utilizando el código en el diagrama. La función UseUint () consume 120,382 unidades de gas, mientras que la función UseUInt8 () consume 166,111 unidades de gas.
Por sí solo, el uso de uint256 es más barato que uint8. Sin embargo, si aplicamos la optimización de empaquetado de variables previamente sugerida, marca la diferencia. Si los desarrolladores pueden empaquetar cuatro variables uint8 en una única ranura de almacenamiento, el costo total de iterar sobre ellas será menor que usar cuatro variables uint256. En este caso, el contrato inteligente puede leer y escribir la ranura de almacenamiento una vez, y cargar las cuatro variables uint8 en la memoria/almacenamiento en una sola operación.
Si los datos pueden ser limitados a 32 bytes, se recomienda usar el tipo de dato bytes32 en lugar de bytes o cadenas de texto. En general, las variables de tamaño fijo consumen menos gas que las variables de tamaño dinámico. Si la longitud en bytes puede ser limitada, intenta elegir la longitud más pequeña, desde bytes1 hasta bytes32.
En Solidity, las listas de datos se pueden representar utilizando dos tipos de datos: Arrays y Mappings, cada uno con una sintaxis y estructura distintas.
Las asignaciones son generalmente más eficientes y rentables en la mayoría de los casos, mientras que los arrays son iterables y admiten el empaquetado de tipos de datos. Por lo tanto, se recomienda priorizar el uso de asignaciones al administrar listas de datos, a menos que se requiera iteración o se pueda optimizar el consumo de Gas mediante el empaquetado de tipos de datos.
Las variables declaradas en los parámetros de la función se pueden almacenar tanto en calldata como en memoria. La diferencia principal es que la memoria puede ser modificada por la función, mientras que calldata es inmutable.
Ten en cuenta este principio: si los parámetros de la función son de solo lectura, es preferible usar calldata en lugar de memory. Esto evita operaciones de copia innecesarias de calldata de función a memory.
Ejemplo 1: Usando la memoria
Cuando se utiliza la palabra clave de memoria, los valores del array se copian de calldata codificado a memoria durante la decodificación de ABI. El costo de ejecución de este bloque de código es de 3,694 unidades de gas.
Ejemplo 2: Usando calldata
Cuando se leen valores directamente desde calldata, se salta la operación de memoria intermedia. Esta optimización reduce el costo de ejecución a solo 2,413 unidades de Gas, lo que resulta en una mejora del 35% en la eficiencia de Gas.
Las variables constantes/inmutables no se almacenan en el almacenamiento del contrato. Estas variables se calculan en tiempo de compilación y se almacenan en el bytecode del contrato. Por lo tanto, su costo de acceso es mucho menor en comparación con las variables de almacenamiento. Se recomienda utilizar las palabras clave Constant o Immutable siempre que sea posible.
Cuando los desarrolladores pueden estar seguros de que las operaciones aritméticas no darán como resultado un desbordamiento o subdesbordamiento, pueden usar la palabra clave sin verificar introducida en Solidity v0.8.0 para evitar comprobaciones innecesarias de desbordamiento o subdesbordamiento y, así, ahorrar costos de gas.
En el diagrama siguiente, la condición restringida i
Además, las versiones del compilador 0.8.0 y superiores ya no requieren el uso de la biblioteca SafeMath, ya que el compilador en sí ahora incluye protección incorporada contra desbordamiento y subdesbordamiento.
El código de los modificadores se incrusta en las funciones que modifican. Cada vez que se utiliza un modificador, se duplica su código, lo que aumenta el tamaño del bytecode y eleva el consumo de Gas. Aquí hay una forma de optimizar el costo de Gas de los modificadores:
Antes de la optimización:
Después de la optimización:
En este ejemplo, al refactorizar la lógica en una función interna _checkOwner(), que se puede reutilizar en el modificador, se reduce el tamaño del bytecode y se reducen los costos de Gas.
Para los operadores || (OR) y && (AND), las operaciones lógicas se evalúan con cortocircuito, lo que significa que si la primera condición es suficiente para determinar el resultado de la expresión lógica, la segunda condición no se evaluará.
Para optimizar el consumo de gas, las condiciones con menores costos de computación deben colocarse primero, de modo que los cálculos potencialmente costosos puedan omitirse.
Si hay funciones o variables no utilizadas en el contrato, se recomienda eliminarlas. Esta es la forma más directa de reducir los costos de implementación del contrato y mantener el tamaño del contrato pequeño.
Aquí hay algunas sugerencias prácticas:
Utilice los algoritmos más eficientes para los cálculos. Si el contrato utiliza directamente ciertos resultados de cálculo, se deben eliminar los cálculos redundantes. Esencialmente, se deben eliminar todos los cálculos no utilizados. En Ethereum, los desarrolladores pueden recibir recompensas de Gas liberando espacio de almacenamiento. Si una variable ya no es necesaria, se debe eliminar utilizando la palabra clave delete o estableciéndola en su valor predeterminado.
Optimización de bucle: Evite operaciones de bucle de alto costo, intente fusionar bucles y mover cálculos repetidos fuera del cuerpo del bucle.
Los contratos precompilados proporcionan funciones de biblioteca complejas como operaciones de criptografía y hash. Dado que el código no se ejecuta en el EVM sino que se ejecuta localmente en el nodo del cliente, se requiere menos gas. El uso de contratos precompilados puede ahorrar gas al reducir la carga computacional necesaria para ejecutar el contrato inteligente.
Los ejemplos de contratos precompilados incluyen el Algoritmo de Firma Digital de Curva Elíptica (ECDSA) y el algoritmo de hash SHA2-256. Al utilizar estos contratos precompilados en contratos inteligentes, los desarrolladores pueden reducir los costos de gas y mejorar la eficiencia de la aplicación.
Para obtener una lista completa de contratos precompilados compatibles con la red Ethereum, consulte este enlace [4].
El ensamblaje en línea permite a los desarrolladores escribir código de bajo nivel pero eficiente que puede ser ejecutado directamente por el EVM, sin utilizar opcodes costosos de Solidity. El ensamblaje en línea también permite un control más preciso sobre el uso de memoria y almacenamiento, reduciendo aún más los costos de gas. Además, el ensamblaje en línea puede realizar algunas operaciones complejas que son difíciles de implementar solo con Solidity, ofreciendo más flexibilidad para optimizar el consumo de gas.
Aquí hay un ejemplo de cómo usar el ensamblador en línea para ahorrar gas:
Como se muestra en el ejemplo anterior, el segundo caso, que utiliza ensamblaje en línea, tiene una eficiencia de Gas más alta en comparación con el caso estándar.
Sin embargo, el uso de ensamblaje en línea también puede introducir riesgos y propenso a errores. Por lo tanto, se debe usar con precaución y se recomienda solo para desarrolladores experimentados.
Las soluciones de Capa 2 pueden reducir la cantidad de datos que necesitan ser almacenados y calculados en la red principal de Ethereum.
Las soluciones de Capa 2 como rollups, sidechains y canales de estado descargan el procesamiento de transacciones de la cadena principal de Ethereum, lo que permite transacciones más rápidas y más baratas.
Al agrupar un gran número de transacciones juntas, estas soluciones reducen la cantidad de transacciones en cadena, lo que a su vez reduce las tarifas de gas. El uso de soluciones de Capa 2 también mejora la escalabilidad de Ethereum, permitiendo que más usuarios y aplicaciones participen en la red sin causar congestión debido a la sobrecarga.
Hay varias herramientas de optimización disponibles, como el optimizador solc, el optimizador de compilación de Truffle y el compilador de Solidity de Remix.
Estas herramientas pueden ayudar a minimizar el tamaño del bytecode, eliminar el código no utilizado y reducir la cantidad de operaciones necesarias para ejecutar contratos inteligentes. Combinado con otras bibliotecas de optimización de Gas como "solmate", los desarrolladores pueden reducir eficazmente los costos de Gas y mejorar la eficiencia de los contratos inteligentes.
Optimizar el consumo de gas es un paso importante para los desarrolladores, ya que no solo minimiza los costos de transacción, sino que también mejora la eficiencia de los contratos inteligentes en las redes compatibles con EVM. Al priorizar las operaciones de ahorro de costos, reducir el uso de almacenamiento, utilizar ensamblaje en línea y seguir otras mejores prácticas discutidas en este artículo, los desarrolladores pueden reducir eficazmente el consumo de gas de los contratos.
Sin embargo, es importante tener en cuenta que durante el proceso de optimización, los desarrolladores deben tener cuidado de evitar la introducción de vulnerabilidades de seguridad. En el proceso de optimizar el código y reducir el consumo de gas, la seguridad inherente del contrato inteligente nunca debe comprometerse.
[1] https://ethereum.org/es/developers/docs/gas/
[2]https://ethereum.github.io/yellowpaper/paper.pdf
[3] https://www.evm.codes/
[4]https://www.evm.codes/precompiled