EIP-7623: La propuesta que fijará nuevamente el precio de Calldata para las transacciones de Ethereum

Las transacciones de blockchain consumen CPU, memoria, almacenamiento y otros recursos cuando se propagan, se ejecutan entre nodos y se almacenan. Por lo tanto, la fijación de precios adecuada de las transacciones es esencial para evitar el abuso de la red y lograr una utilización eficiente de los recursos.

Sin embargo, determinar el precio adecuado para las transacciones ha sido un desafío de larga data en el diseño de protocolos de blockchain. Vitalik Buterin, fundador de Ethereum, aborda este tema en un antiguo documento de investigación :

“Uno de los problemas más desafiantes en el diseño de protocolos de blockchain es cómo limitar y fijar el precio de las transacciones que se incluyen en la cadena”. — Vitalik Buterin

EIP-7623 es una propuesta de mejora de Ethereum (EIP) que tiene como objetivo cambiar el precio de los datos de llamadas para limitar el tamaño máximo de bloque. A diferencia de las propuestas anteriores que simplemente aumentaron el costo de los datos de llamadas, EIP-7623 se centra en minimizar su impacto en las transacciones cotidianas de los usuarios y, al mismo tiempo, lograr una utilización eficiente de los recursos.

En este artículo, explicamos la razón de ser de la modificación del precio de los datos de llamadas utilizados en las transacciones en la capa 1 (L1) de Ethereum y el impacto en los tamaños de los bloques y el rendimiento de la red. También establecemos el contexto de los cambios propuestos en el mecanismo de tarifas de transacción de Ethereum, basándonos en años de investigación sobre el problema de la fijación eficiente de precios de los recursos de la cadena de bloques.

¡Vamos a sumergirnos!

Preparando el escenario: ¿Por qué es tan difícil fijar el precio adecuado de las transacciones?

Ponerle precio a las transacciones de blockchain es difícil porque estimar la cantidad exacta de cada recurso que consume cada transacción es inherentemente complejo. Actualmente, en Ethereum, todos los recursos se representan como unidades unificadas llamadas “gas” y “gas blob” (introducidas con EIP-4844 ).

Existen reglas predefinidas que convierten el consumo de recursos de las transacciones en gas y estas reglas se actualizan periódicamente. Algunos ejemplos de estas reglas son:

• Una transacción que implica un gasto fijo de al menos 21.000 gas, principalmente para la verificación de firmas.

• Consumo de gas predefinido para cada código de operación EVM

  
  

Además, el consumo de gas para los datos de llamadas es una parte integral de estas reglas, algo que es menos conocido pero muy significativo. El precio de los datos de llamadas es crucial porque influye directamente en el tamaño máximo del bloque. Además, afecta a todas las transacciones que utilizan contratos inteligentes, en particular el costo de las transacciones acumuladas que dependen del espacio de los datos de llamadas (en lugar de los blobs) para la disponibilidad de los datos .

¿Por qué es importante el tamaño del bloque?

Ethereum opera en intervalos de 12 segundos, durante los cuales todos los nodos validadores deben propagar bloques y blobs, ejecutar y validar transacciones y dar fe del nuevo bloque. Específicamente, la implementación del cliente Ethereum requiere que los nodos honestos reciban y validen bloques dentro de los primeros 4 segundos del intervalo. Dan fe a los 4 segundos de iniciado el intervalo, lo que significa que se espera que los bloques que lleguen después de 4 segundos no obtengan certificaciones y sean susceptibles de ser reorganizados por el siguiente proponente .

Para minimizar las vistas divididas entre los nodos de Ethereum, el tiempo de ejecución de los bloques y el tiempo de propagación deben tener un límite. Ethereum limita el tiempo de ejecución de los bloques estableciendo un uso máximo de gas, actualmente limitado a 30 millones con un objetivo de 15 millones . Esto significa que los bloques de Ethereum utilizarán aproximadamente 15 millones de gas en promedio, con la capacidad de expandirse y consumir 30 millones de gas en momentos de alta actividad.

Además, cada código de operación EVM tiene un costo de gas predeterminado basado en su consumo de recursos. Por ejemplo, el código de operación SSTORE es más costoso que las operaciones más simples (por ejemplo, la suma aritmética, ADD) porque implica acceder y modificar el trie de estado. Este precio diferenciado de los códigos de operación EVM, junto con el límite total de gas, tenía como objetivo restringir el tiempo total de ejecución.

Si bien el límite de gas de un bloque puede limitar en cierta medida el tiempo de ejecución del bloque, el tiempo de propagación del bloque permanece sin restricciones explícitas. El tamaño del bloque es un factor importante que afecta el tiempo de propagación en las cadenas de bloques públicas. Por ejemplo, los tamaños de bloque más grandes aumentan la carga de la red y los requisitos de ancho de banda; si el tamaño del bloque excede en gran medida el ancho de banda de la mayoría de los nodos, los nodos tardan más en propagarse por completo y recibir el bloque, lo que aumenta el riesgo de bloques perdidos o reorganizados. (Esta es la razón por la que el protocolo Bitcoin (pre- Segwit ) tenía un límite de tamaño de bloque de 1 MB para evitar mayores tasas de bifurcación y garantizar la seguridad y los bajos requisitos de nodos de la cadena de bloques).

En la actualidad, Ethereum no tiene un límite de tamaño de bloque establecido explícitamente. Sin embargo, el tamaño máximo teórico de bloque se puede estimar considerando el límite de gas, el costo de los datos de llamada, la tasa de compresión, etc. Aunque el tamaño de bloque actual de Ethereum es de aproximadamente 2,78 MB (excluidos los blobs), el precio actual de los datos de llamada permite cargas útiles EL de hasta 7,15 MB, mientras que el tamaño promedio es mucho menor, alrededor de 100 KB.

Si cargas útiles tan grandes se propagaran consistentemente durante 10 minutos, podrían ascender a aproximadamente 42,9 MB, lo que es significativamente más grande que los tamaños de bloque típicos en otras redes blockchain.

Esto podría potencialmente sobrecargar la red Ethereum y provocar que los nodos tengan diferentes vistas por un corto período en un escenario de ataque DoS donde las cargas útiles de 7,15 MB continúan por un tiempo.

En la práctica, el tamaño de bloque promedio en Ethereum hoy es de aproximadamente 125 KB, lo que indica una brecha significativa con respecto al tamaño de bloque máximo. Esto plantea otra preocupación con respecto a la ineficiencia en la utilización de recursos. Por ejemplo, si la red puede manejar bloques de 1 MB seguidos, una gran discrepancia entre el tamaño de bloque promedio y 1 MB sugiere que Ethereum tiene más capacidad para la funcionalidad de disponibilidad de datos (DA), pero no la está utilizando de manera efectiva.

Al limitar el tamaño máximo de bloque y alinear el tamaño promedio de bloque más cerca de este máximo, Ethereum podría reducir los riesgos de consenso y, al mismo tiempo, lograr una utilización más eficiente de los recursos. Por eso, la EIP-7623 se centra en el tamaño máximo de bloque posible, que se ve muy afectado por el precio de los datos de llamadas.

¿Qué es Calldata en Ethereum?

Calldata es un campo en una transacción que se usa normalmente para indicar qué funciones se deben llamar y qué parámetros se deben pasar. Por ejemplo, si desea acuñar un NFT, debe incluir el método 'mint' y las características específicas del NFT en el campo calldata. El siguiente ejemplo muestra la primera transacción de acuñación de un CryptoPunk en 2017.

Los datos de la llamada (a los que se hace referencia como "datos de entrada" en la figura) contienen el nombre de la función getPunk , representado por 0xc81d1d5b, y el índice NFT, representado por 0x00001eb0 (7856 en hexadecimal). Si solo transfiere ETH y no interactúa con ningún contrato inteligente, el campo calldata es nulo ( 0x ).

Además de su propósito principal de pasar parámetros a los contratos inteligentes, calldata también se usa para registrar notas simples o para que los rollups almacenen sus datos de transacciones. En otras palabras, calldata no siempre necesita interactuar con contratos inteligentes o seguir reglas estrictas; puede contener valores arbitrarios.

Aprovechando esta flexibilidad, los rollups optimistas como Optimism y Arbitrum, algunos rollups ZK (validez), datos de transacciones de rollup comprimidos posteriormente y estados actualizados en el campo calldata de sus transacciones de secuenciación. Aunque EIP-4844 ha habilitado la disponibilidad de datos a través de blobs en lugar de calldata, calldata sigue siendo el preferido por los rollups pequeños que no necesitan los 128 KB completos de un blob para un solo lote.

Calldata se utiliza a menudo para la funcionalidad DA porque es la forma que consume menos gas para publicar datos grandes en la EVM. Es por eso que el tamaño máximo de bloque está limitado por el precio de calldata. El peor escenario ocurre cuando un bloque se llena con transacciones con fines DA que usan pequeñas cantidades de gas pero grandes tamaños de datos.

Actualmente, el costo de los datos de llamada es de 4 gas por byte cero y 16 gas por byte distinto de cero. Los datos de llamada se pueden comprimir mediante compresión rápida ( EIP-706 ) y el tamaño de la transacción no puede superar los 125 KB. El cálculo preciso del tamaño máximo del bloque es complejo debido a la naturaleza variable de las relaciones de compresión, pero se sabe que el bloque puede aumentar hasta ~2,78 MB.

Si los bloques de 2,78 MB continúan de forma consecutiva debido a ciertas razones (por ejemplo, ataques de spam), la red podría sobrecargarse y los nodos podrían tener vistas divididas debido a las bajas velocidades de propagación. Más nodos podrían dar fe de diferentes bloques como la cadena canónica, lo que aumenta el riesgo de no alcanzar un consenso. Para evitar esto, una solución simple podría ser aumentar el costo de los datos de llamada; por ejemplo, duplicar el costo de los datos de llamada a 8 gas por bytes cero y 32 gas por byte distinto de cero podría reducir aproximadamente el tamaño máximo de bloque a la mitad.

Sin embargo, este enfoque podría perjudicar las transacciones normales de los usuarios. Aumentar los costos de los datos de llamadas solo para evitar el peor escenario posible podría resultar en una pérdida mayor que en una ganancia, dado que el tamaño promedio de los bloques actualmente es de solo 125 KB y no plantea problemas significativos.

¿Cuál es la motivación para EIP-7623?

La EIP-7623 difiere levemente de otras propuestas que simplemente aumentan el costo de los datos de llamadas. En lugar de un ajuste general del precio de los datos de llamadas, la EIP-7623 se centra en aumentar el costo del gas específicamente para las transacciones que parecen servir a fines de disponibilidad de datos (DA).

¿Qué significa esto? Si el gas utilizado en una transacción es insuficiente en comparación con el tamaño total de los datos cargados, se considera una transacción con propósito DA y se cobra significativamente más por los datos de llamada. Por el contrario, si una transacción consume suficiente gas en relación con el tamaño de los datos, se considera una transacción sin propósito DA y se cobra lo mismo que en la actualidad.

Se puede establecer una analogía útil entre los datos de llamadas en Ethereum y las bolsas de plástico en el mundo real. Cuando compramos productos o comestibles, a menudo nos dan bolsas de plástico para transportarlos, generalmente a un costo muy bajo o incluso gratis. Sin embargo, si las personas pudieran comprar una cantidad ilimitada de bolsas de plástico, sería perjudicial para el medio ambiente.

Una posible solución es restringir el uso de bolsas de plástico a los clientes que compran suficientes productos o cobran un precio más alto, como 1 dólar por bolsa. Esto es análogo al enfoque EIP-7623, que funciona como una forma de impuesto pigouviano. Impone costos más altos a las transacciones que utilizan una gran cantidad de datos de llamadas pero una cantidad insuficiente de gas, lo que promueve un uso más eficiente de los recursos. Al aplicar costos más agresivos a quienes utilizan principalmente los datos de llamadas para la disponibilidad de datos en lugar de una combinación equilibrada de datos y ejecución, el protocolo pretende garantizar una utilización más eficiente y sostenible de los recursos de la red.

¿Por qué orientar las transacciones DA en Ethereum?

No hay nada inherentemente malo en las transacciones que utilizan Ethereum para la disponibilidad de datos. EIP-7623 no desalienta a Ethereum de funcionar como una capa de disponibilidad de datos; más bien, desalienta el uso de calldata con el propósito de almacenar datos de transacciones y fomenta indirectamente el uso de blobs para DA en su lugar. Esta propuesta tiene como objetivo separar la capa de ejecución de la capa de disponibilidad de datos, lo que permite que cada capa gestione eficientemente la demanda y prediga mejor los casos extremos.

De esta manera, la EIP-7623 busca mejorar la eficiencia y la previsibilidad de la gestión de recursos de Ethereum, al tiempo que limita la superficie de ataque DoS. Esta separación garantiza que cada capa pueda manejar sus funciones específicas de manera más eficaz, lo que en última instancia contribuye a una red Ethereum más robusta y escalable.

Descripción general de las especificaciones EIP-7623

El cálculo actual de gas de una transacción es el siguiente:

Los 21,000 de la especificación anterior son el gas mínimo que se cobra por cualquier transacción. Además, STANDARD_TOKEN_COST tokens_in_calldata representa el gas utilizado para calldata, que EIP-7623 intenta solucionar principalmente. Aquí, tokens_in_calldata es una combinación ponderada simple de bytes cero y no cero, que se calcula mediante tokens_in_calldata = zero_bytes_in_calldata + 4 * nonzero_bytes_in_calldata .

STANDARD_TOKEN_COST actualmente está establecido en 4, por lo que el costo de gas de zero_bytes_in_calldata es 4 y nonzero_bytes_in_calldata es 16.

evm_gas_used es el gas utilizado para la ejecución de una transacción, que cubre principalmente las interacciones con contratos inteligentes. Las transacciones que no tienen un propósito de DA suelen tener un componente evm_gas_used grande.

Cuando una transacción crea un nuevo contrato, el término isContractCreation se convierte en 1, lo que implica un gasto adicional de gas para crear y almacenar el nuevo contrato. Como la creación del contrato no es el objetivo aquí, estableceremos este término en cero.

EIP-7623 propone el siguiente ajuste al cálculo del gas total:

En el nuevo cálculo, max(blue box, red box) compara el gas calculado por el método actual (cuadro azul) con los datos de llamada TOTAL_COST_FLOOR_PER_TOKEN (cuadro rojo). El cuadro azul es exactamente el mismo que el método de cálculo de gas actual. El cuadro rojo, que es nuevo en EIP-7623, representa el valor que juzga si una transacción es para fines de DA. A partir del 1 de enero de 2025, se propone que TOTAL_COST_FLOOR_PER_TOKEN sea 10, que es mucho más alto que el STANDARD_TOKEN_COST de 4.

En otras palabras, si una transacción no gasta suficiente evm_gas_used , el cuadro rojo probablemente tendrá un valor más alto que el valor del cuadro azul, lo que la marca como una transacción con propósito DA. En consecuencia, la transacción se cobrará a la tasa TOTAL_COST_FLOOR_PER_TOKEN , pagando efectivamente un poco menos de 3 veces más por calldata. Por el contrario, la mayoría de las transacciones de propósito general gastan suficiente evm_gas_used , por lo que max(blue box, red box) tomará por defecto el valor del cuadro azul, manteniendo el método de costo de gas actual.

¿Qué tipos de transacciones se ven afectadas por EIP-7623?

Para determinar qué transacciones se ven afectadas por EIP-7623, necesitamos identificar la condición en la que el cuadro rojo (cálculo de gas nuevo) es más alto que el cuadro azul (cálculo de gas actual).

Al ignorar el término de creación del contrato y sustituir valores en los parámetros, obtenemos la siguiente condición: Las transacciones incurrirán en un costo de gas mayor si el gas consumido para la ejecución de EVM es menor a 6 veces los tokens en calldata.

Para que esto sea más intuitivo, dividamos ambos lados por 4 tokens_in_calldata . Recordemos que 6 tokens_in_calldata es el gas pagado por calldata en una transacción.

Esta ecuación final indica que si el gas utilizado para la ejecución de EVM es menos del doble del gas utilizado para calldata, la transacción incurrirá en tarifas más altas para calldata.

¿Cuánto aumentarán los costos de Calldata después de EIP-7623?

Supongamos que el gas mínimo para una transacción es 21 000, el gas utilizado para la ejecución de EVM es k y el gas utilizado para los datos de llamada es kx. El costo total de la transacción se puede expresar de la siguiente manera:

Según el cálculo actual (sin EIP-7623), el coste sería de 21.000+k+kx. Por tanto, la tasa de aumento con EIP-7623 sería:

La tasa de aumento en función de k se representa gráficamente a continuación:

Para comprender el impacto práctico, examinemos las estadísticas de uso de gas para los métodos de funcionamiento comunes, centrándonos en aquellos que resultan familiares para la mayoría de los usuarios.

Entre las diversas funciones de intercambio en los intercambios descentralizados, swap(string, address, uint256, bytes) es la más utilizada.

En promedio, utiliza 5,152 para calldata y 175,742 para EVM , y esto representa un valor 34 veces mayor. La función transfer(address, uint256) , utilizada para transferir tokens ERC20, consume alrededor de 24,501 gas para la ejecución de EVM, aproximadamente 40 veces más que los 620 gas utilizados para calldata.

De manera similar a estas funciones, la mayoría de las transacciones diarias de los usuarios tienen una diferencia significativa entre el gas utilizado para los datos de llamada y la ejecución de EVM, lo que significa que es poco probable que se vean afectadas por EIP-7623.

El análisis proporcionado por el investigador de Ethereum Toni Wahrstätter muestra que si se aplica la EIP-7623, el 3,02 % de las transacciones recientes de Ethereum se verían afectadas. Su análisis también identifica qué métodos de función se verán afectados y estima el aumento de costos para esos métodos. Un análisis adicional proporcionado por Wahrstätter muestra que, en el caso de las transacciones recientes en Ethereum, el 3,02 % de las transacciones se verían afectadas si se aplica la EIP-7623.

Su sitio también muestra qué métodos de función se verán realmente afectados y cuánto aumentaría el precio de esos métodos.

Entre las funciones afectadas por EIP-7623, la más utilizada es addSequencerL2BatchFromOrigin() , que se emplea habitualmente para secuenciar transacciones de acumulación en Ethereum. Otro método afectado es commitBatches() , que se utiliza con frecuencia en transacciones de acumulación. Se espera que estas dos funciones experimenten los aumentos de costos más significativos, con un aumento estimado del 150 % en los costos totales de gas al utilizar estos métodos.

Sin embargo, los rollups pueden utilizar blobs para la publicación de datos, y muchos rollups, como Arbitrum One y Base, ya lo están haciendo . En consecuencia, es poco probable que los rollups que utilizan blobs para la publicación de datos se vean muy afectados por el aumento de los costos impuestos por EIP-7623.

Análisis del impacto de EIP-7623 en los tamaños de bloque

La EIP-7623 aumenta el costo del gas para las transacciones que utilizan grandes cantidades de datos de llamadas. Esto significa que los ataques de spam, que dependen en gran medida de los datos de llamadas, requerirían aproximadamente tres veces más costo de gas, lo que reduciría efectivamente el tamaño máximo de bloque de 2,54 MB a aproximadamente 0,72 MB. En consecuencia, la red Ethereum estaría mejor equipada para manejar los peores escenarios en los que se propagan bloques grandes de forma continua.

La reducción del tamaño máximo de bloque posible crea una oportunidad para aumentar la cantidad de blobs incluidos por bloque. Actualmente, la cantidad máxima de blobs es 6, cada uno de 128 KiB de tamaño. Si se adopta EIP-7623 y se mantiene el mismo tamaño máximo de bloque, podría ser posible aumentar la cantidad máxima de blobs a aproximadamente 18, lo que significa un aumento de 3 veces en el TPS (transacciones por segundo) máximo de los rollups.

Este cálculo implica una simplificación excesiva, ya que los métodos de propagación de blobs y bloques difieren. Sin embargo, la principal ventaja es la mayor separación entre las capas de ejecución y disponibilidad de datos. Dado que el gas de blobs y el gas de ejecución tienen mercados de tarifas separados, las perturbaciones en un mercado no afectarán directamente al otro.

Esta separación simplifica la consecución de la eficiencia del capital porque resulta más fácil controlar el objetivo y los recursos máximos que la red Ethereum puede manejar dentro de un solo bloque.

¿Cuáles son otras consideraciones relacionadas con la implementación de EIP-7623?

Si bien EIP-7623 ofrece beneficios significativos, podría afectar potencialmente a los rollups pequeños al requerir el uso de blobs en lugar de datos de llamadas. Para los rollups de baja demanda, el gran tamaño de blob de 128 KiB podría obligarlos a esperar más tiempo hasta que puedan llenar el blob completo. Esta situación aumenta la necesidad de protocolos de uso compartido de blobs , lo que permite que varios rollups compartan el gran espacio de blobs para una mejor eficiencia de costos.

Aunque la tarifa base de blobs actualmente es muy baja (lo que hace que los blobs sean un espacio de DA económico), un aumento repentino en la demanda podría suponer una carga significativa para estos rollups. Sin un aumento simultáneo en la cantidad de blobs por bloque, EIP-7623 podría hacer que los rollups que envían transacciones de DA sean más competitivos, ya que la capacidad total para DA está disminuyendo en general. Es necesario evaluar si la cantidad de blobs debería aumentarse simultáneamente para adaptarse a este cambio.

Otra consideración es decidir los criterios para el umbral en el que las transacciones se verán afectadas por esta actualización. Hay compensaciones entre el tamaño del bloque y la experiencia del usuario. Por ejemplo, establecer el umbral de forma demasiado agresiva podría reducir en gran medida el tamaño máximo del bloque, pero muchas transacciones podrían tener que pagar más gas por los datos de llamada.

Si bien el cambio en el tamaño máximo de bloque es explícito y vívido, es difícil estimar y cuantificar cuánto se vería afectado Ethereum al requerir costos de gas más altos para transacciones con fines de DA. Este umbral solo se puede establecer socialmente.

Además, los criterios dependen en gran medida de otros parámetros establecidos por las operaciones de EVM o el límite de gas. Por ejemplo, si Ethereum aumentara el límite de gas por bloque a 300 millones en el futuro, el umbral de EIP-7623 también debería modificarse para mantener el tamaño máximo de bloque.

Conclusión

EIP-7623 es una propuesta de mejora de Ethereum que apunta a reducir el tamaño máximo de bloque mediante el ajuste del costo de los datos de llamada, específicamente en las transacciones con fines DA. Este ajuste podría aumentar potencialmente el costo de las transacciones DA que no sean blobs hasta en un 300 %, mientras que la mayoría de las transacciones de los usuarios cotidianos no se verán afectadas.

A lo largo de este artículo, hemos explorado la motivación detrás de la propuesta, sus implicaciones, los tipos de transacciones afectadas y las posibles preocupaciones que pueden surgir. Espero que este escrito te ayude a comprender más sobre esta propuesta reciente y te brinde información detallada sobre su contenido. Si estás interesado y quieres saber más, puedes seguir el análisis y la explicación de Toni Wahrstätter y participar en la discusión abierta en el foro Ethereum Magicians.