Para abordar el problema de la alta tarifa de gas en Ethereum, se ha propuesto EIP-4844 como una solución provisional. Pero, ¿qué es y cómo funciona? ¡Una guía no tan técnica para explicar un término técnico!
El problema de la alta tarifa de gas en Ethereum ha llevado a EIP-4844 (también conocido como proto-danksharding), un intento de introducir una solución provisional para aumentar el espacio de bloques dentro de la red mediante la implementación de un formato de transacciones que de otro modo se supone que se implementarán en sharding, una estrategia para escalar Ethereum.
Dado que la implementación de fragmentos puede llevar un tiempo, para reducir la alta cantidad de tarifas de gas que los usuarios están pagando actualmente, se está implementando este nuevo formato de transacción. Dado que esta es una solución provisional, solo se ha agregado una cantidad limitada de espacio de bloques, que, en el despliegue completo de cadenas de fragmentos, agregaría aproximadamente 16 MB de espacio de bloques.
Para comprender más sobre esta propuesta de mejora de Ethereum y cómo ayuda a la cadena, ¡profundicemos un poco más!
Índice de contenido:
¿Cómo ayudará EIP-4844 a los usuarios?
La propuesta EIP 4844 está tratando de crear una solución «provisional» para que la red pueda liberarse de las transacciones cada vez mayores al agregar aproximadamente 2 MB de espacio a los bloques.
Como puede imaginar, esto solo brinda cierto alivio tanto a la red como a los usuarios que ahora pueden confiar en las tarifas de gas más bajas.
Cuando se implementen los paquetes acumulativos, se basarán en los datos fragmentados (que también se conocen como blob) para garantizar que la red se haya aliviado y que los usuarios no incurran en tarifas de gas extremadamente altas.
Otra cosa a tener en cuenta aquí es que se ha hablado previamente de varias versiones diferentes de este EIP. Sin embargo, esta versión tiene como objetivo introducir solo el formato que se utilizará para los datos fragmentados, sin fragmentarlos.
Uno de los principales desafíos para esto es la implementación en sí. Si solo se está implementando una parte del proceso de fragmentación en esta ronda, ¿cómo se implementaría el resto? Si bien el proceso puede parecer simple, dependería de cómo la comunidad decida llevar esto adelante. Hasta ahora, ya se han implementado varios cambios a nivel del suelo, mientras que algunos de ellos aún están en proceso.
La principal compensación en el diseño de este EIP es la de implementar más ahora versus tener que implementar más tarde: ¿implementamos el 25% del trabajo en el camino hacia la fragmentación completa, o el 50%, o el 75%?
Antes de esto, la mayoría de estas actualizaciones han dependido de la hoja de ruta rollupcentric para Ethereum. Proto-danksharding, por otro lado, solo proporciona los formatos de transacción y las reglas de verificación para que el proceso se ejecute, sin implementarlo por completo. Como parte de esto, se crea un nuevo tipo de transacción aquí. Se conoce como la «transacción de transporte de blobs». Intenta incluir los blobs como datos dentro de los bloques. Estos son utilizados por soluciones de capa 2 para ayudar a escalar Ethereum, sin depender de la Máquina Virtual Ethereum (EVM) para acceder a ella.
La necesidad de Proto-danksharding
Actualmente, la red ha sido diseñada para acomodar transacciones que constituyen aproximadamente 90 Kb de espacio de bloque para cada bloque. Incluso si el modelo de tarifa de gas se ajustara de manera que se acomodara a tamaños de bloque más grandes, el tamaño máximo podría aumentar hasta 18 MB. Sin embargo, eso en sí mismo sería demasiado costoso tanto para los validadores participantes como para los usuarios. Por otro lado, si utilizamos el mercado dinámico de tarifas que ya se ha implementado como parte de EIP 1559, eso nos ayuda a acomodar más transacciones sin sobrecargar demasiado la red.
Proto-danksharding hace que las cosas sean un poco menos complicadas. El proceso implica la creación de una transacción que contiene datos en blobs de tamaño relativamente fijo mediante la introducción de un límite superior al número de blobs que se pueden incluir en el bloque. Estos son almacenados por la cadena de balizas, y solo requieren una confirmación de compromiso de la Máquina Virtual Ethereum (EVM).
Solo hay una diferencia significativa entre EIP-4488 y proto-danksharding, que es en términos de implementación. Mientras que el primero introduce cambios mínimos hoy en día para crear una solución provisional, el segundo requiere una implementación más exhaustiva para que se minimice la cantidad de esfuerzo necesario para poner más adelante. La complejidad de implementar la fragmentación solo se limita a la cadena de balizas y no a la capa de ejecución.
El aumento del tamaño del bloque también puede tener repercusiones en el tamaño del bloque y la capacidad de los validadores para almacenar datos en sus recursos de hardware. Según las estimaciones, puede haber un aumento a más de 2,5 TB de datos por año. Una de las formas de reducir esto es eliminar los datos de blob que envejecen después de un cierto período de tiempo, digamos 30 días o más.
¿Cómo accederán los usuarios a los blobs antiguos después de la implementación de EIP-4844?
Puede ser, pero el objetivo de EIP-4844 no es garantizar el almacenamiento permanente de datos históricos de la cadena de bloques, ya que puede acumular muchos gastos en los participantes de la red. Más bien, se ha propuesto que los datos se pueden almacenar en otro lugar de manera que sean fácilmente accesibles como varias aplicaciones / protocolos que proporcionan ese servicio. De esta manera, los datos históricos pueden ser accedidos por aquellos que los necesitan.
Reflexiones finales
A medida que nos acercamos a la fusión, hay varios cambios por los que está pasando el EVM. Algunos de estos cambios ayudarán a escalar Ethereum para que pueda habilitarse para admitir más transacciones y ofrecer más escalabilidad. Proto-danksharding es uno de ellos.
