¿Qué es el crecimiento histórico?

La historia en Ethereum consiste en todos los bloques y transacciones ejecutadas a lo largo de su vida. Esta información es necesaria para sincronizar la cadena desde el bloque génesis hasta su estado actual. El crecimiento histórico se refiere a la acumulación de nuevos bloques y transacciones con el tiempo.

La Figura 1 muestra la relación entre el crecimiento histórico, diversas métricas de protocolo y las limitaciones de hardware de los nodos de Ethereum. A diferencia del crecimiento del estado, el crecimiento histórico está limitado por un conjunto diferente de limitaciones de hardware. Esta presión de crecimiento afecta a la E/S de red porque los nuevos bloques y transacciones deben ser transmitidos a través de la red. También sobrecarga el espacio de almacenamiento del nodo, ya que cada nodo de Ethereum almacena una copia completa del registro histórico. Si el crecimiento histórico supera estas limitaciones de hardware, los nodos ya no podrán alcanzar un consenso estable con sus pares. Para obtener una visión general del crecimiento del estado y otros cuellos de botella de escalabilidad, consulte Parte 1de esta serie.

Figura 1: Cuello de botella de expansión de Ethereum

Hasta hace poco, la mayor parte del rendimiento de red de cada nodo se utilizaba para transmitir registros históricos (por ejemplo, nuevos bloques y transacciones). Esto cambió con la introducción de blobs en el Dencunhard fork. Los bloques ahora constituyen una parte significativa de la actividad de la red de nodos. Sin embargo, los bloques no se consideran parte del registro histórico porque 1) los nodos los almacenan solo durante 2 semanas antes de descartarlos, y 2) no son necesarios para reproducir la cadena desde Génesis. Debido a (1), los bloques no aumentan significativamente la carga de almacenamiento en cada nodo de Ethereum. Discutiremos los bloques con más detalle más adelante en este artículo.

En este artículo, nos centraremos en el crecimiento de los datos históricos y su relación con el crecimiento estatal. Dado que el crecimiento estatal y histórico comparten algunas limitaciones de hardware superpuestas, son cuestiones interrelacionadas; abordar una puede ayudar a mitigar la otra.

¿Qué tan rápido se desarrolla la historia?

La Figura 2 muestra la tasa de crecimiento histórico a lo largo del tiempo desde el origen de Ethereum. Cada barra vertical representa el crecimiento de un mes. El eje Y representa el número de GB agregados a la historia en ese mes. Las transacciones se categorizan por su "dirección de destino" y su tamaño se determina utilizando suRLPrepresentación de bytes. Los contratos que no pueden ser identificados fácilmente se clasifican como "desconocidos". La categoría "otros" incluye una larga lista de categorías más pequeñas como infraestructura y juegos.

Varias conclusiones clave se pueden extraer de este gráfico:

1. La tasa de crecimiento histórico es aproximadamente de 6 a 8 veces más rápida que el crecimiento estatal: El crecimiento histórico alcanzó recientemente su punto máximo en 36.0 GiB/mes y actualmente está en 19.3 GiB/mes. El crecimiento estatal alcanzó un máximo de alrededor de 6.0 GiB/mes y ahora está en 2.5 GiB/mes. Una comparación entre el crecimiento histórico y estatal, tanto en términos de tasa como de tamaño acumulado, se puede encontrar más adelante en este artículo.
2. La tasa de crecimiento histórico se estaba acelerando rápidamente antes de Dencun: mientras que el crecimiento estatal ha sido aproximadamente lineal a lo largo de los años (ver Parte 1) el crecimiento histórico ha sido superlineal. El crecimiento lineal resulta en un aumento cuadrático en el tamaño general, mientras que el crecimiento superlineal resulta en un aumento más rápido que el cuadrático. Esta aceleración se detuvo abruptamente después de Dencun, marcando la primera desaceleración significativa en el crecimiento histórico en la historia de Ethereum.
3. El crecimiento histórico reciente proviene principalmente de Rollups: Cada L2 publica una copia de sus transacciones de vuelta al mainnet, generando una cantidad significativa de datos históricos y convirtiendo a los rollups en el mayor contribuyente al crecimiento histórico en el último año. Sin embargo, Dencun permite que los L2 utilicen blobs en lugar de registros históricos para publicar sus datos de transacciones, por lo que los rollups ya no generan la mayoría de los registros históricos de Ethereum. Examinaremos los rollups con más detalle más adelante en este artículo.

¿Cuáles son los mayores contribuyentes a la historia de Ethereum?

La cantidad de datos históricos generados por cada categoría de contrato revela cómo han evolucionado con el tiempo los patrones de uso de Ethereum. La figura 3 muestra las contribuciones relativas de diversas categorías de contrato. Esto utiliza los mismos datos que la Figura 2, normalizados al 100%.

Los datos revelan cuatro épocas distintas de patrones de uso de Ethereum:

Era temprana (Púrpura): En los primeros años de Ethereum, hubo una actividad mínima en la cadena. La mayoría de estos contratos iniciales ahora son difíciles de identificar y están etiquetados como "desconocidos" en el gráfico.

Era ERC-20 (Verde): El estándar ERC-20se finalizó a finales de 2015 pero no ganó una tracción significativa hasta 2017 y 2018. Para 2019, los contratos ERC-20 se convirtieron en la categoría más grande en crecimiento histórico.

Era DEX/DeFi (Marrón): Los contratos DEX y DeFi aparecieron en cadena tan temprano como en 2016 y comenzaron a llamar la atención en 2017. Sin embargo, no se convirtieron en la categoría histórica más grandehasta el Verano DeFi de 2020. Los contratos DeFi y DEX alcanzaron más del 50% del crecimiento histórico en varios momentos en 2021 y 2022.

Era de Rollup (Gris): A principios de 2023, los L2 Rollups comenzaron a ejecutarse de manera consistentemás transacciones que la red principal.Esto coincidió con que sus contratos generaran una gran parte de los datos históricos, representando aproximadamente dos tercios del crecimiento histórico de Ethereum en los meses previos a Dencun.

Cada era representa patrones de uso cada vez más complejos en Ethereum. Con el tiempo, esta complejidad puede verse como una forma de escalado de Ethereum, no capturada por métricas simples como transacciones por segundo.

En los datos más recientes (abril de 2024), los rollups ya no generan la mayoría de los registros históricos. No está claro si el crecimiento histórico futuro estará dominado por DEX y DeFi o si surgirán nuevos patrones de uso.

¿Qué pasa con las manchas?

La introducción de blobs en la bifurcación dura de Dencun alteró significativamente la dinámica del crecimiento histórico, permitiendo que los Rollups utilicen blobs económicos en lugar de registros históricos para publicar datos. La Figura 4 se centra en la tasa de crecimiento histórico alrededor de la fecha de la actualización de Dencun. Este gráfico es similar a la Figura 2, pero cada barra vertical representa un día en lugar de un mes.

Varias conclusiones clave se pueden sacar de este gráfico:

El crecimiento histórico de Rollups ha disminuido en aproximadamente dos tercios desde Dencun: La mayoría de los rollups han pasado de utilizar datos de llamadas a blobs, reduciendo significativamente la cantidad de datos históricos que generan. Sin embargo, a partir de abril de 2024, algunos rollupstodavía no he cambiado de los datos de llamadas a los blobs.

El Crecimiento Histórico Total Ha Disminuido en Aproximadamente un Tercio Desde Dencun: Dencun ha reducido principalmente el crecimiento histórico de los rollups. El crecimiento histórico de otras categorías de contratos ha aumentado ligeramente. Incluso después de Dencun, el crecimiento histórico sigue siendo aproximadamente ocho veces el crecimiento del estado (detalles en la próxima sección).

A pesar de la reducción en el crecimiento histórico, los blobs siguen siendo una nueva adición a Ethereum. Actualmente no está claro dónde se estabilizará el crecimiento histórico en presencia de blobs.

¿Cuánto crecimiento histórico es aceptable?

Aumentar el límite de gas aumentará la tasa de crecimiento histórica. Por lo tanto, las propuestas para aumentar el límite de gas (como Pump the Gas) debe considerar la relación entre el crecimiento histórico y los cuellos de botella de hardware en cada nodo.

Para determinar una tasa de crecimiento histórico aceptable, es útil examinar primero cuánto tiempo pueden sostener el estado actual las redes de nodos modernas y el hardware de nodos de almacenamiento. El hardware de red puede mantener el statu quo indefinidamente porque es poco probable que las tasas de crecimiento históricas vuelvan a los niveles anteriores a Dencun antes de que aumenten los límites de gas. Sin embargo, la carga de almacenamiento de registros históricos aumenta con el tiempo. Según las políticas de almacenamiento actuales, la unidad de almacenamiento de cada nodo eventualmente se llenará de historial.

La figura 5 ilustra la carga de almacenamiento de los nodos de Ethereum con el tiempo y también predice cómo esta carga puede aumentar en los próximos 3 años. Las predicciones se realizan utilizando tasas de crecimiento a partir de abril de 2024. Esta tasa puede aumentar o disminuir en el futuro debido a cambios en los patrones de uso o límites de gas.

Varias conclusiones clave se pueden extraer de este gráfico:

El espacio de almacenamiento utilizado por la historia es aproximadamente tres veces mayor que el del estado: esta disparidad aumentará con el tiempo, ya que la tasa de crecimiento de la historia es aproximadamente ocho veces mayor que la del estado.

Umbral crítico alrededor de 1,8 TiB: Muchos nodos se verán obligados a actualizar sus unidades de almacenamiento en este punto. Una unidad de 2 TB, tamaño común, solo proporciona 1,8 TiB de espacio utilizable. Tenga en cuenta que TB (terabytes) y TiB (tebibytes, = 1024^4 bytes) son unidades diferentes. Para muchos operadores de nodos, el umbral crítico "real" es incluso más bajo porque los validadores deben ejecutar un cliente de consenso junto con un cliente de ejecución después de la fusión.

Umbral alcanzado en 2-3 años: Cualquier aumento en el límite de gas acelerará esta línea de tiempo. Alcanzar este umbral impondrá una carga significativa de mantenimiento en los operadores de nodos, lo que necesitará la compra de hardware adicional, como un $300 unidad de disco NVME.

Almacenamiento separado para datos históricos: A diferencia de los datos de estado, los datos históricos son solo para agregar y se acceden con mucha menos frecuencia. Por lo tanto, teóricamente podrían almacenarse por separado de los datos de estado en medios de almacenamiento más baratos. Algunos clientes, como Geth, ya soporta esta separación.

La E/S de red como una limitación de hardware: Además de la capacidad de almacenamiento, la E/S de red es otra restricción importante de hardware para el crecimiento histórico. A diferencia de la capacidad de almacenamiento, los límites de E/S de red no representarán problemas inmediatos para los nodos, pero serán significativos para futuros aumentos del límite de gas.

Para comprender cuánto crecimiento histórico puede soportar la capacidad de red de un nodo Ethereum típico, es necesario describir la relación entre el crecimiento histórico y varias métricas de salud de la red, como la tasa de reorganización, fallos de ranura, falta de finalidad, atestaciones faltantes, fallos del comité de sincronización y retrasos en la propuesta de bloques. Analizar estas métricas está más allá del alcance de este artículo, pero se pueden encontrar en investigaciones anteriores sobre la salud de la capa de consenso [1] [2] [3] 4]Además, la Fundación Ethereum @ethpandaops/xatu-overview">El proyecto Xatu ha estado construyendo conjuntos de datos públicos para facilitar tales análisis.

¿Cómo resolver el crecimiento histórico?

El crecimiento histórico es un problema más fácil de abordar que el crecimiento del estado. El propuestoEIP-4444casi resuelve por completo este problema. Este EIP cambia el requisito para cada nodo de retener toda la historia de Ethereum a retener solo un año de historia. Una vez que se implemente el EIP-4444, incluso con aumentos significativos en el límite de gas a largo plazo, el almacenamiento de datos ya no será un cuello de botella para la escalabilidad de Ethereum. El EIP-4444 es esencial para la sostenibilidad a largo plazo de la red, ya que de lo contrario, los datos históricos crecerán lo suficientemente rápido como para necesitar actualizaciones regulares de hardware para los nodos de la red.

La figura 6 muestra cómo EIP-4444 afectaría la carga de almacenamiento de cada nodo durante los próximos 3 años. Esto es igual que la Figura 4, con la adición de líneas más finas que representan la carga de almacenamiento después de la implementación de EIP-4444.

Varias conclusiones clave se pueden extraer de este gráfico:

EIP-4444 reducirá a la mitad la carga de almacenamiento actual: la carga de almacenamiento disminuirá de 1.2 TiB a 633 GiB.

EIP-4444 Estabilizará la Carga de Almacenamiento Histórico: Suponiendo una tasa constante de crecimiento histórico, los datos históricos se descartarán a la misma velocidad a la que se generan.

Después de la EIP-4444, pasarán muchos años antes de que la carga de almacenamiento alcance el nivel actual: esto se debe a que el crecimiento del estado, que es más lento que el crecimiento histórico, será el único factor que aumentará la carga de almacenamiento.

EIP-4444 Todavía impondrá cierta carga de almacenamiento debido a un año de datos históricos: Sin embargo, esta carga será manejable incluso si Ethereum se expande a nivel mundial. Una vez que el método de manejo de datos históricos demuestre ser confiable, el período de retención de un año en EIP-4444 podría acortarse a unos meses, semanas o incluso menos.

¿Cómo preservar la historia de Ethereum?

EIP-4444 plantea la pregunta: si los nodos de Ethereum en sí mismos no preservan el historial, ¿cómo debería preservarse? La historia es crucial para la verificación, contabilidad y análisis de Ethereum, por lo que debe preservarse. Afortunadamente, preservar la historia es sencillo, ya que solo requiere 1/n de proveedores de datos honestos, en comparación con el problema de consenso de estado, que necesita de 1/3 a 2/3 de participantes honestos. Los operadores de nodos pueden verificar la autenticidad de cualquier conjunto de datos históricos: 1) reproduciendo todas las transacciones desde el Genesis; y 2) comprobando si estas transacciones reproducen la misma raíz de estado que la punta de la cadena actual.

Existen múltiples métodos para preservar la historia, cada uno de los cuales debería ser implementado en paralelo para maximizar las posibilidades de preservación:

Torrents / P2P: Torrentsson el método más simple y robusto. Los nodos de Ethereum pueden empaquetar periódicamente partes de la historia y compartirlas como archivos torrent públicos. Por ejemplo, un nodo podría crear un nuevo archivo torrent de historia cada 100,000 bloques. Algunos clientes de nodos, como Erigon, ya realizan este proceso de manera no estandarizada. Para estandarizar este proceso, todos los clientes de nodos deben utilizar el mismo formato de datos, parámetros y red P2P. Los nodos pueden optar por participar en esta red en función de su capacidad de almacenamiento y ancho de banda. La ventaja de los torrents es el uso de estándares abiertos maduros respaldados por un gran ecosistema de herramientas de datos.

Portal Network: El Portal NetworkEs una nueva red diseñada específicamente para alojar datos de Ethereum. Este enfoque es similar a torrents pero proporciona características adicionales para facilitar la verificación de datos. La ventaja de la Red Portal es que estas capas adicionales de verificación ofrecen a los clientes livianos utilidades de verificación y consulta eficientes para conjuntos de datos compartidos.

Hospedaje en la nube: Servicios de almacenamiento en la nube como AWSS3o CloudflareR2ofrecen opciones baratas y de alto rendimiento para preservar la historia. Sin embargo, este método conlleva más riesgos legales y operativos comerciales, ya que estos servicios en la nube no siempre estarán dispuestos o serán capaces de alojar datos de criptomonedas.

Los desafíos restantes de implementación son más sociales que técnicos. La comunidad de Ethereum necesita coordinarse en detalles de implementación específicos para que puedan integrarse directamente en cada cliente de nodo. Especialmente, sincronizar completamente desde Génesis (en lugar de sincronización de instantáneas) requerirá recuperar historial de proveedores de datos históricos en lugar de nodos de Ethereum. Estos cambios no requieren un hard fork y pueden implementarse antes del próximo hard fork de Ethereum, Pectra.

Las L2 también pueden utilizar todos estos métodos para preservar los datos de blob que publican en la mainnet. La preservación de blob es 1) más desafiante debido al mayor volumen total de datos; 2) menos crítica porque los blobs no son necesarios para reproducir la historia de la mainnet. Sin embargo, la preservación de blob es necesaria para que cada L2 reproduzca su propia historia. Por lo tanto, alguna forma de preservación de blob es crucial para todo el ecosistema de Ethereum. Además, si las L2 desarrollan una infraestructura robusta de almacenamiento de blobs, también pueden almacenar fácilmente datos históricos de L1.

Una comparación directa de los conjuntos de datos almacenados por varias configuraciones de nodos antes y después del EIP-4444 es útil. La Figura 7 muestra la carga de almacenamiento de los tipos de nodos de Ethereum. Los datos de estado incluyen cuentas y contratos, los datos históricos incluyen bloques y transacciones, y los datos de archivo son un conjunto de índices de datos opcionales. Los recuentos de bytes en la tabla se basan en instantáneas recientes de reth, pero las cifras deberían ser aproximadamente comparables en otros clientes de nodos.

Figura 7: Carga de almacenamiento de los tipos de nodos de Ethereum

En lenguaje,

1. Los nodos de archivo almacenan datos de estado, datos históricos y datos de archivo. Se utilizan cuando se necesita una consulta fácil del estado de la cadena histórica.
2. Los nodos completos solo almacenan datos históricos y datos de estado. La mayoría de los nodos hoy son nodos completos. La carga de almacenamiento de los nodos completos es aproximadamente la mitad que la de los nodos de archivo.
3. Después de EIP-4444, los nodos completos solo almacenarán datos de estado y los datos históricos del último año. Esto reducirá la carga de almacenamiento de 1,2 TiB a 633 GiB y estabilizará el uso de almacenamiento para datos históricos.
4. Los nodos sin estado, también conocidos como "nodos ligeros", no almacenan ninguno de estos conjuntos de datos y pueden validar instantáneamente en la punta de la cadena. Este tipo de nodo se vuelve posible una vez Verkle intentao otros esquemas de compromiso estatal se añaden a Ethereum.

Finalmente, existen propuestas adicionales de ecosistema que tienen como objetivo limitar la tasa de crecimiento histórica en lugar de simplemente adaptarse a la tasa actual. Estas son útiles para mantener los límites de IO de la red a corto plazo y los límites de almacenamiento a largo plazo. Si bien EIP-4444 es esencial para la sostenibilidad a largo plazo de la red, estas otras EIP ayudarán a Ethereum a escalar de manera más eficiente en el futuro:

EIP-7623: Esta propuesta sugiere volver a tasar los datos de llamadas para que las transacciones con datos de llamadas excesivos sean más costosas. Hacer que estos patrones de uso sean más costosos animará a algunos a cambiar de datos de llamadas a blobs, lo que reducirá la tasa de crecimiento histórica.

EIP-4488: Esta propuesta impone límites sobre la cantidad total de datos de llamadas que se pueden incluir en cada bloque, aplicando un control más estricto sobre la tasa de crecimiento histórico.

Estas EIP son más fáciles de implementar que EIP-4444 y pueden servir como medidas provisionales antes de que EIP-4444 esté listo para producción.

Conclusión

El objetivo de este artículo es proporcionar una comprensión basada en datos de cómo opera el crecimiento histórico y cómo abordar este problema. Gran parte de los datos presentados en este artículo tradicionalmente han sido difíciles de acceder, por lo que nuestro objetivo es ofrecer ideas novedosas sobre el problema del crecimiento histórico.

El crecimiento histórico como cuello de botella para la escalabilidad de Ethereum no ha recibido suficiente atención. Incluso sin aumentar los límites de gas, la práctica actual de retener el historial en Ethereum requeriría que muchos nodos actualizaran su hardware en pocos años. Afortunadamente, este no es un problema particularmente difícil de resolver. Se han delineado soluciones claras en EIP-4444. Creemos que debería haber una aceleración en la implementación de este EIP para dejar espacio para futuros aumentos en los límites de gas.

Si estás interesado en la investigación de escalabilidad de Ethereum, por favor contactastorm@paradigm.xyzygeorgios@paradigm.xyz.Nos encantaría escuchar sus perspectivas sobre este tema y explorar posibles colaboraciones. Los datos y el código utilizados en este artículo pueden ser encontrado enGithub.

Agradecimientos

Muchas gracias a Thomas Thiery、Equipo Beiko、Toni Wahrstaetter、Oliver NordbjergyRoman Krasiukpara su revisión y comentarios. Gracias a lAchal Srinivasanpara las cifras proporcionadas en la Figura 1 y la Figura 7.

Descargo de responsabilidad：

1. Este artículo está reimpreso de [Marsbit]. Todos los derechos de autor pertenecen al autor original [Storm Slivkoff, Georgios Konstantopoulos]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo y lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.