¿Estamos finalmente listos para un aumento del límite de gas?
Ha habido una creciente discusión en torno a la posibilidad de aumentar el rendimiento de gas de Ethereum, ya sea aumentando el límite de gas o reduciendo el tiempo de ranura. El argumento clave a favor de esto es que los requisitos de hardware para ejecutar un validador han disminuido constantemente en los últimos cuatro años.
Además, han surgido 2 enfoques para aumentar el límite de gas:
En esta publicación, analizaré los posibles escenarios de caso peor y caso promedio en cuanto a los requisitos de ancho de banda, computacionales y de almacenamiento si el límite de gas se duplicara.
Cuando Ethereum se lanzó en 2015, el límite de gas se estableció inicialmente en 5,000 gas por bloqueCon el tiempo, este límite experimentó cambios significativos:
- Tras el hard fork Tangerine Whistle y más específicamente la implementación de EIP-150, el límite de gas se aumentó a 5.5 millones. Este ajuste se realizó como parte de una reevaluación de ciertos opcodes intensivos en E/S en respuesta a ataques de denegación de servicio (DoS).
En julio de 2017, el límite de gas se aumentó a 6.7 millones y continuó aumentando:
- Diciembre de 2017: ~8 millones
- Septiembre de 2019: ~10 millones
– Agosto de 2020: 12.5 millones
- Abril de 2021: 15 millones
Según EIP-1559, también hay un límite máximo de gas (o "límite máximo"), que se establece en el doble del objetivo. Esto significa que un bloque puede incluir transacciones con hasta 30 millones de gas.
Y durante casi cuatro años, no ha habido ningún aumento en el límite de gas en absoluto.
Para responder a esta pregunta, necesitamos analizar tres aspectos de los requisitos de hardware: ancho de banda, computación y almacenamiento si el límite de gas se eleva a 60 millones hoy en día.
Al considerar un aumento en el límite de gas, el almacenamiento se destaca como el mayor cuello de botella y preocupación para la red de Ethereum. La razón de esto radica en el crecimiento histórico del tamaño del estado de Ethereum y la tensión continua que esto coloca en los validadores.
Hay dos tipos de "crecimiento" en Ethereum:
Crecimiento del Estado
Crecimiento de la historia
El estado de Ethereum, la colección de todos los saldos de cuentas, el código de contrato inteligente y el almacenamiento, continúa expandiéndose a medida que se procesan más transacciones y se implementan contratos inteligentes. Desde su inicio, el tamaño del estado ha crecido significativamente, con períodos de crecimiento acelerado impulsados por la congestión de la red, el aumento de la actividad de transacciones y el auge de las finanzas descentralizadas (DeFi) y los NFT. Actualmente, el crecimiento del estado es de aproximadamente 2.5 GB por mes, o 30 GB por año.
Este crecimiento del estado puede llevar a los siguientes problemas:
– Tiempos de acceso más lentos al disco
– Mayor requerimientos de hardware
Sin embargo, al momento de escribir esto, ninguno de estos problemas es particularmente significativo. De hecho, la diferencia en el tiempo de acceso entre sistemas de almacenamiento que difieren en solo unos pocos gigabytes es bastante insignificante debido a la complejidad algorítmica de las consultas, que suele ser logarítmica. Los requisitos de almacenamiento también son insignificantes, ya que el costo de hardware nuevo está disminuyendo a un ritmo que supera con creces el crecimiento relativamente pequeño en el tamaño del estado de 30 GB por año. Incluso si se incrementara a 60 GB/año, la diferencia probablemente no destacaría y aún sería superada por el progreso tecnológico en hardware de todos modos.
Este aumento en el tamaño del estado todavía es superado por el progreso tecnológico por un margen significativo. Incluso si el límite de gas se duplicara, el costo del hardware continúa disminuyendo de manera exponencial, lo que hace que el hardware requerido sea más barato con el tiempo.
Sin embargo, vale la pena señalar que pronto, los stakers en solitario necesitarán más de 2 TB de almacenamiento para ejecutar un validador en Ethereum. Esto elevará efectivamente el requisito a 4 TB de almacenamiento, ya que la mayoría del hardware se vende en potencias de dos. Paradójicamente, esto significa que Ethereum también podría hacer uso del almacenamiento adicional, ya que los validadores ya tendrían que invertir en el hardware de mayor capacidad, independientemente de si el límite de gas aumenta o no.
NOTA: No hay análisis promedio vs peor caso sobre almacenamiento porque manipular constantemente bloques durante un período prolongado de tiempo (semanas y meses) es un esfuerzo increíblemente costoso.
Para justificar mis afirmaciones de que el costo de almacenamiento ha estado disminuyendo a tasas exponenciales, podemos echar un vistazo a las fluctuaciones de precios en USD de 1 GB de SSD en los últimos cuatro años:
Disculpa por la mala calidad, pero la publicación de donde la tomé estaba así
Parece que cada dos años, el costo de un GB de SSD tiende a reducirse a la mitad.
Si comparamos esto con el crecimiento del almacenamiento y del estado, la diferencia es insignificante. El crecimiento actual de Ethereum es lineal, mientras que los costos de hardware tienden a disminuir a una tasa exponencial.
Encontré un gráfico más revelador sobre esta tendencia con los costos de almacenamiento, pero es de una publicación de Reddit y no de una publicación científica real (aunque los resultados coinciden).
El caso promedio para el ancho de banda en Ethereum se parece a 2 MB/s; sin embargo, la mayor parte de este número proviene de los blobs chismorreantes de CL y aggreGates. Cuando se trata de aumentar el límite de gas, lo único que hay que tener en cuenta es el tamaño del bloque.
Actualmente, el tamaño máximo de bloque registrado es de 270 KB, y el tamaño de bloque actual después de Deneb es de 75 KB. Si duplicáramos esto, el cambio sería equivalente a un aumento de 0.5-2 blobs en comparación con el máximo histórico y el promedio actual, lo que equivaldría a un aumento del ≈ 2-5% en el ancho de banda del nodo (entrante y saliente). Entonces, en el caso promedio, no es un cambio significativo. De hecho, tres blobs adicionales serían mucho más perjudiciales.
El peor caso se ha calculado en 1.7MB, lo que se convertiría en 3.4MB (+50% más de ancho de banda necesario para el pico). Esto no es mucho, pero sigue siendo significativo. La razón por la que creo que esto no es mucho es que tal ataque de denegación de servicio sería bastante costoso y el pico sería un +50% de los requisitos promedio actuales, algo que ya se tiene en cuenta. Como estaba diciendo, llenar bloques de 15 millones de gas hasta el borde durante varios bloques consecutivos es muy costoso. Por lo tanto, aunque un atacante podría lanzar potencialmente un ataque de denegación de servicio durante unos pocos bloques, tendría que gastar una cantidad significativa de dinero para hacerlo. Además, tendría que competir con otras transacciones para ingresar al bloque, lo que lo hace aún más costoso.
En cualquier caso, independientemente de las opiniones sobre los números, un aumento en el costo de los datos de llamada solucionaría por completo este problema, así que no estoy preocupado por eso en ningún caso. Además, si se aumenta el límite de gas a través de EIP-7783, estos riesgos son insignificantes y controlables.
Para empezar, el cálculo y los tiempos de bloque nunca fueron un problema, pero aquí vamos.
El caso promedio para el cálculo de bloques suele ser <1 segundo, incluso para máquinas lentas con discos malos. No hay mucho que discutir aquí, en promedio, esto nunca fue el cuello de botella.
El peor de los casos parece no estar claro y depende del cliente. Después de hablar con algunos equipos de clientes, parece que el consenso es que el único problema sería que algunos códigos de operación no escalan bien (como MODEXP).
Sin embargo, cualquier vector de DoS aquí se puede solucionar con una reevaluación, y si el aumento del límite de gas se realiza con EIP-7783, entonces estos riesgos son insignificantes.
En general, parece que el crecimiento del almacenamiento no es el cuello de botella para aumentar el límite de gas, ya que el hardware como el almacenamiento es fácil de actualizar. Sin embargo, el ancho de banda representa una amenaza mayor, ya que es mucho más difícil de escalar. Afortunadamente, con EIP-7783, los riesgos relacionados con el ancho de banda y los posibles aumentos en la computación se reducen de manera efectiva. No obstante, podría ser prudente cambiar el precio del costo de los datos de llamadas para garantizar una seguridad adicional (aunque, en mi opinión, no es probable que sea necesario).
En mi opinión personal, es posible aumentar el límite de gas actual en un 33% o incluso duplicarlo hoy si se hace con el aumento gradual introducido EIP-7783.
Creo que todavía es demasiado pronto para hacerlo a través de EIP-7782, porque sería punitivo para la TVP y la SSF. Sin embargo, una vez que se resuelvan, definitivamente se debe una disminución en los tiempos de las tragamonedas.
¿Estamos finalmente listos para un aumento del límite de gas?
Ha habido una creciente discusión en torno a la posibilidad de aumentar el rendimiento de gas de Ethereum, ya sea aumentando el límite de gas o reduciendo el tiempo de ranura. El argumento clave a favor de esto es que los requisitos de hardware para ejecutar un validador han disminuido constantemente en los últimos cuatro años.
Además, han surgido 2 enfoques para aumentar el límite de gas:
En esta publicación, analizaré los posibles escenarios de caso peor y caso promedio en cuanto a los requisitos de ancho de banda, computacionales y de almacenamiento si el límite de gas se duplicara.
Cuando Ethereum se lanzó en 2015, el límite de gas se estableció inicialmente en 5,000 gas por bloqueCon el tiempo, este límite experimentó cambios significativos:
- Tras el hard fork Tangerine Whistle y más específicamente la implementación de EIP-150, el límite de gas se aumentó a 5.5 millones. Este ajuste se realizó como parte de una reevaluación de ciertos opcodes intensivos en E/S en respuesta a ataques de denegación de servicio (DoS).
En julio de 2017, el límite de gas se aumentó a 6.7 millones y continuó aumentando:
- Diciembre de 2017: ~8 millones
- Septiembre de 2019: ~10 millones
– Agosto de 2020: 12.5 millones
- Abril de 2021: 15 millones
Según EIP-1559, también hay un límite máximo de gas (o "límite máximo"), que se establece en el doble del objetivo. Esto significa que un bloque puede incluir transacciones con hasta 30 millones de gas.
Y durante casi cuatro años, no ha habido ningún aumento en el límite de gas en absoluto.
Para responder a esta pregunta, necesitamos analizar tres aspectos de los requisitos de hardware: ancho de banda, computación y almacenamiento si el límite de gas se eleva a 60 millones hoy en día.
Al considerar un aumento en el límite de gas, el almacenamiento se destaca como el mayor cuello de botella y preocupación para la red de Ethereum. La razón de esto radica en el crecimiento histórico del tamaño del estado de Ethereum y la tensión continua que esto coloca en los validadores.
Hay dos tipos de "crecimiento" en Ethereum:
Crecimiento del Estado
Crecimiento de la historia
El estado de Ethereum, la colección de todos los saldos de cuentas, el código de contrato inteligente y el almacenamiento, continúa expandiéndose a medida que se procesan más transacciones y se implementan contratos inteligentes. Desde su inicio, el tamaño del estado ha crecido significativamente, con períodos de crecimiento acelerado impulsados por la congestión de la red, el aumento de la actividad de transacciones y el auge de las finanzas descentralizadas (DeFi) y los NFT. Actualmente, el crecimiento del estado es de aproximadamente 2.5 GB por mes, o 30 GB por año.
Este crecimiento del estado puede llevar a los siguientes problemas:
– Tiempos de acceso más lentos al disco
– Mayor requerimientos de hardware
Sin embargo, al momento de escribir esto, ninguno de estos problemas es particularmente significativo. De hecho, la diferencia en el tiempo de acceso entre sistemas de almacenamiento que difieren en solo unos pocos gigabytes es bastante insignificante debido a la complejidad algorítmica de las consultas, que suele ser logarítmica. Los requisitos de almacenamiento también son insignificantes, ya que el costo de hardware nuevo está disminuyendo a un ritmo que supera con creces el crecimiento relativamente pequeño en el tamaño del estado de 30 GB por año. Incluso si se incrementara a 60 GB/año, la diferencia probablemente no destacaría y aún sería superada por el progreso tecnológico en hardware de todos modos.
Este aumento en el tamaño del estado todavía es superado por el progreso tecnológico por un margen significativo. Incluso si el límite de gas se duplicara, el costo del hardware continúa disminuyendo de manera exponencial, lo que hace que el hardware requerido sea más barato con el tiempo.
Sin embargo, vale la pena señalar que pronto, los stakers en solitario necesitarán más de 2 TB de almacenamiento para ejecutar un validador en Ethereum. Esto elevará efectivamente el requisito a 4 TB de almacenamiento, ya que la mayoría del hardware se vende en potencias de dos. Paradójicamente, esto significa que Ethereum también podría hacer uso del almacenamiento adicional, ya que los validadores ya tendrían que invertir en el hardware de mayor capacidad, independientemente de si el límite de gas aumenta o no.
NOTA: No hay análisis promedio vs peor caso sobre almacenamiento porque manipular constantemente bloques durante un período prolongado de tiempo (semanas y meses) es un esfuerzo increíblemente costoso.
Para justificar mis afirmaciones de que el costo de almacenamiento ha estado disminuyendo a tasas exponenciales, podemos echar un vistazo a las fluctuaciones de precios en USD de 1 GB de SSD en los últimos cuatro años:
Disculpa por la mala calidad, pero la publicación de donde la tomé estaba así
Parece que cada dos años, el costo de un GB de SSD tiende a reducirse a la mitad.
Si comparamos esto con el crecimiento del almacenamiento y del estado, la diferencia es insignificante. El crecimiento actual de Ethereum es lineal, mientras que los costos de hardware tienden a disminuir a una tasa exponencial.
Encontré un gráfico más revelador sobre esta tendencia con los costos de almacenamiento, pero es de una publicación de Reddit y no de una publicación científica real (aunque los resultados coinciden).
El caso promedio para el ancho de banda en Ethereum se parece a 2 MB/s; sin embargo, la mayor parte de este número proviene de los blobs chismorreantes de CL y aggreGates. Cuando se trata de aumentar el límite de gas, lo único que hay que tener en cuenta es el tamaño del bloque.
Actualmente, el tamaño máximo de bloque registrado es de 270 KB, y el tamaño de bloque actual después de Deneb es de 75 KB. Si duplicáramos esto, el cambio sería equivalente a un aumento de 0.5-2 blobs en comparación con el máximo histórico y el promedio actual, lo que equivaldría a un aumento del ≈ 2-5% en el ancho de banda del nodo (entrante y saliente). Entonces, en el caso promedio, no es un cambio significativo. De hecho, tres blobs adicionales serían mucho más perjudiciales.
El peor caso se ha calculado en 1.7MB, lo que se convertiría en 3.4MB (+50% más de ancho de banda necesario para el pico). Esto no es mucho, pero sigue siendo significativo. La razón por la que creo que esto no es mucho es que tal ataque de denegación de servicio sería bastante costoso y el pico sería un +50% de los requisitos promedio actuales, algo que ya se tiene en cuenta. Como estaba diciendo, llenar bloques de 15 millones de gas hasta el borde durante varios bloques consecutivos es muy costoso. Por lo tanto, aunque un atacante podría lanzar potencialmente un ataque de denegación de servicio durante unos pocos bloques, tendría que gastar una cantidad significativa de dinero para hacerlo. Además, tendría que competir con otras transacciones para ingresar al bloque, lo que lo hace aún más costoso.
En cualquier caso, independientemente de las opiniones sobre los números, un aumento en el costo de los datos de llamada solucionaría por completo este problema, así que no estoy preocupado por eso en ningún caso. Además, si se aumenta el límite de gas a través de EIP-7783, estos riesgos son insignificantes y controlables.
Para empezar, el cálculo y los tiempos de bloque nunca fueron un problema, pero aquí vamos.
El caso promedio para el cálculo de bloques suele ser <1 segundo, incluso para máquinas lentas con discos malos. No hay mucho que discutir aquí, en promedio, esto nunca fue el cuello de botella.
El peor de los casos parece no estar claro y depende del cliente. Después de hablar con algunos equipos de clientes, parece que el consenso es que el único problema sería que algunos códigos de operación no escalan bien (como MODEXP).
Sin embargo, cualquier vector de DoS aquí se puede solucionar con una reevaluación, y si el aumento del límite de gas se realiza con EIP-7783, entonces estos riesgos son insignificantes.
En general, parece que el crecimiento del almacenamiento no es el cuello de botella para aumentar el límite de gas, ya que el hardware como el almacenamiento es fácil de actualizar. Sin embargo, el ancho de banda representa una amenaza mayor, ya que es mucho más difícil de escalar. Afortunadamente, con EIP-7783, los riesgos relacionados con el ancho de banda y los posibles aumentos en la computación se reducen de manera efectiva. No obstante, podría ser prudente cambiar el precio del costo de los datos de llamadas para garantizar una seguridad adicional (aunque, en mi opinión, no es probable que sea necesario).
En mi opinión personal, es posible aumentar el límite de gas actual en un 33% o incluso duplicarlo hoy si se hace con el aumento gradual introducido EIP-7783.
Creo que todavía es demasiado pronto para hacerlo a través de EIP-7782, porque sería punitivo para la TVP y la SSF. Sin embargo, una vez que se resuelvan, definitivamente se debe una disminución en los tiempos de las tragamonedas.