Comenzamos a construir Reth en 2022 para proporcionar resiliencia a Ethereum L1 y resolver la escalabilidad de la capa de ejecución en la Capa 2.

Hoy estamos emocionados de compartir el camino de Reth hacia 1 gigagas por segundo en L2 en 2024, y nuestra hoja de ruta a largo plazo para ir más allá de eso.

Invitamos al ecosistema a colaborar con nosotros mientras empujamos la frontera del rendimiento y la evaluación rigurosa en criptomonedas.

¿Estamos escalados ya?

Hay un camino muy simple para que las criptomonedas alcancen escala global y escapen de la especulación como el caso de uso dominante: Las transacciones deben ser baratas y rápidas.

¿Cómo se mide el rendimiento? ¿Qué significa gas por segundo?

El rendimiento se mide típicamente por la métrica "Transacciones por Segundo" (TPS). Especialmente para Ethereum y otras blockchains EVM, una medida más matizada y tal vez precisa es "gas por segundo". Esta métrica refleja la cantidad de trabajo computacional que la red puede manejar cada segundo, donde "gas" es una unidad que mide el esfuerzo computacional requerido para ejecutar operaciones como transacciones o contratos inteligentes.

La estandarización en torno al gas por segundo como métrica de rendimiento permite una comprensión más clara de la capacidad y eficiencia de una cadena de bloques. También ayuda a evaluar las implicaciones de costos en el sistema, protegiéndose contra posibles ataques de denegación de servicio (DOS) que podrían explotar medidas menos matizadas. Esta métrica ayuda a comparar el rendimiento entre diferentes cadenas compatibles con la Máquina Virtual Ethereum (EVM).

Proponemos a la comunidad de EVM adoptar gas por segundo como una métrica estándar, junto con la incorporación otras dimensiones de la tarificación del gascrear un estándar de rendimiento integral.

¿Dónde estamos hoy?

La cantidad de gas por segundo se determina dividiendo el uso de gas objetivo por bloque entre el tiempo por bloque. Aquí mostramos la cantidad actual de gas por segundo y la latencia a través de varias cadenas EVM L1 y L2 (no exhaustivas):

Enfatizamos gas por segundo para evaluar a fondo el rendimiento de la red EVM, capturando tanto los costos de cálculo como de almacenamiento. Redes como Solana, Sui o Aptos no están incluidas debido a sus modelos de costos distintos. Alentamos los esfuerzos hacia la armonización de modelos de costos en todas las redes blockchain para permitir comparaciones exhaustivas y justas.

Estamos trabajando en una suite de referencia continua para Reth replicando carga de trabajo real, si quieres colaborar en esto, por favor ponte en contacto. Necesitamos un TPC Benchmarkpara nodos.

¿Cómo llegará Reth a 1 gigagas por segundo? ¿Más allá de eso?

Fuimos parcialmente motivados para construir Reth en 2022 por la apremiante necesidad de tener un cliente diseñado específicamente para rollups a escala web. Creemos que tenemos un camino prometedor por delante.

Reth ya alcanza 100-200mgas/s durante la sincronización en vivo (incluyendo la recuperación de los remitentes, la ejecución de transacciones y el cálculo del trie en cada bloque); 10 veces más nos lleva a nuestro objetivo a corto plazo de 1 gigagas/s.

A medida que avanzamos en el desarrollo de Reth, nuestro plan de escalado debe equilibrar la escalabilidad con la eficiencia:

• Escalamiento Vertical: Nuestro objetivo aquí es maximizar el uso de cada “caja” a su máximo potencial. Al optimizar cómo cada sistema individual maneja transacciones y datos, podemos mejorar enormemente el rendimiento general, al mismo tiempo que lo hacemos más eficiente para los operadores de nodos individuales.
• Escalado horizontal: A pesar de las optimizaciones, el volumen abrumador de transacciones a escala web supera lo que cualquier servidor único puede manejar. Para abordar esto, queremos implementar una arquitectura escalada horizontalmente, similar a un modelo Kubernetes para nodos blockchain. Esto significa distribuir la carga de trabajo en varios sistemas para asegurar que ningún nodo único se convierta en un cuello de botella.

Las optimizaciones que estamos explorando aquí no implican resolvercrecimiento estatal, que estamos investigando por separado.

Aquí tienes un resumen de cómo pretendemos llegar allí:

En toda la pila también estamos optimizando para E/S y CPU utilizando el modelo de actores, para permitir que cada parte de la pila se implemente como un servicio con un control fino sobre su utilización. Finalmente, estamos evaluando activamente bases de datos alternativas, pero aún no hemos decidido sobre un candidato.

El mapa de escalado vertical de Reth

Nuestro objetivo aquí es maximizar el rendimiento y la eficiencia de un único servidor o portátil que ejecute Reth.

EVM Just-In-Time & Ahead-of-Time

En entornos de blockchain como la Máquina Virtual Ethereum (EVM), la ejecución del bytecode se realiza a través de un intérprete, que procesa secuencialmente las instrucciones. Este método introduce sobrecarga porque no ejecuta instrucciones nativas de ensamblaje directamente, en lugar de operar a través de la capa de VM.

La compilación Just-In-Time (JIT) aborda esto convirtiendo el bytecode a código de máquina nativo justo antes de la ejecución, mejorando así el rendimiento al evitar el proceso interpretativo de la MV. Esta técnica, que compila los contratos en código de máquina optimizado de antemano, está bien establecida en otras MV como Java y WebAssembly.

Sin embargo, JIT puede ser vulnerable a código malicioso diseñado para explotar el proceso JIT, o puede ser demasiado lento para ejecutarse en vivo durante la ejecución. Reth Ahead-of-Time (AOT) compilará los contratos de mayor demanda y los almacenará en disco, para evitar que el bytecode no confiable intente abusar de nuestro paso de compilación de código nativo durante la ejecución en vivo.

Hemos estado trabajando en un compilador JIT/AOT para Revm, actualmente integrado con Reth. Abriremos el código fuente de esto en las próximas semanas una vez que hayamos terminado nuestras pruebas de rendimiento. Alrededor del 50% del tiempo de ejecución se gasta en el intérprete EVM en promedio, por lo que esto debería proporcionar una mejora de ejecución EVM de ~2x, aunque en algunos casos más intensivos en cálculos podría tener un impacto aún mayor. Compartiremos nuestras pruebas de rendimiento e integración de nuestro propio JIT EVM en Reth en las próximas semanas.

EVM paralelo

El concepto de una Máquina Virtual Ethereum Paralela (Parallel EVM) permite el procesamiento simultáneo de transacciones, divergiendo del modelo tradicional de ejecución en serie del EVM. Tenemos 2 caminos por delante aquí:

1. Historical Sync: En la sincronización histórica, podemos calcular el mejor horario de paralelización posible mediante el análisis de transacciones pasadas e identificando todos los conflictos de estado históricos. Vea nuestro primer intento en una rama antigua en Github.
2. Sincronización en vivo: Para la sincronización en vivo, podemos usar Block STM-like técnicas para ejecutar especulativamente sin ninguna información adicional como listas de acceso. Este algoritmo tiene un rendimiento pobre durante períodos de fuerte contención de estado, por lo que queremos explorar el cambio entre la ejecución en serie y paralela dependiendo de la forma de la carga de trabajo, así como predecir estáticamente qué espacios de almacenamiento se accederán para mejorar la calidad del paralelismo. Consulte una prueba de concepto realizada por un equipo de tercerosaquí.

Basándonos en nuestro análisis histórico, ~80% de las ranuras de almacenamiento de Ethereum se acceden de forma independiente, lo que significa que el paralelismo podría generar hasta 5 veces de mejora en la ejecución de EVM.

Mejorando el Compromiso del Estado

Nosotros recientemente escribí sobreel impacto de la raíz del estado en el rendimiento y las diferencias entre el modelo de base de datos Reth de otros clientes, así como por qué es importante.

En el modelo Reth, calcular la raíz del estado es un proceso separado de ejecutar transacciones (ver nuestro código) que permite el uso de tiendas KV estándar que no necesitan saber nada sobre el trie. Actualmente, esto representa más del 75% del tiempo total para sellar un bloque y es un área muy emocionante para optimizar.

Identificamos las siguientes 2 "victorias fáciles" que pueden brindarnos un rendimiento de 2-3 veces en la raíz del estado, sin necesidad de realizar cambios en el protocolo:

1. Raíz de estado completamente paralelizada: En este momento, solo volvemos a calcular el trie de almacenamiento para las cuentas modificadas en paralelo, pero podemos ir más allá y también calcular el trie de cuentas en paralelo mientras los trabajos de raíz de almacenamiento se completan en segundo plano.
2. Raíz de estado en línea: Prefetch nodos de árbol intermedios desde el disco durante la ejecución notificando al servicio de raíz de estado sobre las ranuras de almacenamiento y las cuentas afectadas.

Yendo más allá de eso, vemos algunos caminos a seguir al divergir del comportamiento de la raíz del estado de Ethereum L1.

1. Raíz de Estado menos frecuente: En lugar de calcular la raíz de estado en cada bloque, cálculela cada T bloques. Esto reduce el porcentaje general del tiempo invertido en la raíz de estado en todo el sistema y podría ser la solución más fácil y efectiva.
2. Raíz del estado rezagada: En lugar de tener que calcular la raíz del estado en el mismo bloque, permítale rezagarse unos cuantos bloques. Esto permite que la ejecución avance sin bloquearse en el cálculo de la raíz del estado.
3. Reemplace el codificador RLP & Keccak256: En lugar de codificar con RLP, puede ser más barato simplemente concatenar los bytes y usar una función hash más rápida como Blake3.
4. Trie más ancho: aumentar la N-aridad del árbol, para reducir la amplificación de E/S debido a la profundidad logN del trie.

Hay algunas preguntas aquí:

1. ¿Cuáles son los efectos de segundo orden de los cambios anteriores en los clientes ligeros, L2s, puentes, coprocesadores y otros protocolos que dependen de pruebas frecuentes de cuenta y almacenamiento?
2. ¿Podemos optimizar tanto el compromiso del estado para la demostración de SNARK como la velocidad de ejecución nativa?
3. ¿Cuál es el compromiso estatal más amplio que podemos obtener con las herramientas que tenemos disponibles? ¿Qué efectos de segundo orden hay alrededor del tamaño del testigo?

Hoja de ruta de escalabilidad horizontal de Reth

Ejecutaremos varios de los puntos anteriores a lo largo de 2024 y alcanzaremos nuestro objetivo de 1gigagas/seg.

Sin embargo, la escalabilidad vertical finalmente encuentra límites físicos y prácticos. Ninguna máquina individual puede manejar las necesidades informáticas del mundo. Creemos que hay 2 caminos por delante aquí, que nos permiten escalar introduciendo más cajas a medida que llega más carga:

Multi-Rollup Reth

Las pilas L2 de hoy requieren ejecutar varios servicios para seguir la cadena: L1 CL, L1 EL, la función de derivación L1 -> L2 (que puede estar incluida con el L2 EL), y el L2 EL. Si bien es excelente para la modularidad, esto se complica al ejecutar múltiples pilas de nodos. ¡Imagina tener que ejecutar 100 rollups!

Queremos permitir el lanzamiento de rollups en el mismo proceso que Reth y reducir el costo operativo de ejecutar miles de rollups a casi cero.

Ya estamos en marcha con esto con nuestro Proyectos de extensiones de ejecución ([1], [2]) más en las próximas semanas aquí.

Reth nativo de la nube

Los secuenciadores de alto rendimiento pueden tener suficiente demanda en una sola cadena que necesiten escalar más allá de una sola máquina. Esto no es posible en las implementaciones de nodos monolíticos de hoy en día.

Queremos permitir la ejecución de nodos Reth nativos de la nube, implementados como una pila de servicios que puede escalar automáticamente con la demanda de cálculo y utilizar el almacenamiento de objetos en la nube aparentemente infinito para la persistencia. Esta es una arquitectura común en proyectos de bases de datos sin servidor como NeonDB, CockroachDB o Amazon Aurora.

Ver pensamientos inicialesde nuestro equipo sobre algunas formas en las que podríamos abordar este problema.

Perspectiva

Tenemos la intención de implementar este plan de forma incremental para todos los usuarios de Reth. Nuestra misión es brindar a todos acceso a 1 gigagas/s y más allá. Probaremos nuestras optimizaciones en Reth AlphaNet, y esperamos que las personas construyan nodos de alto rendimiento modificados utilizando Reth como un SDK.

Hay algunas preguntas para las que aún no hemos encontrado respuestas.

• ¿Cómo puede Reth ayudar a mejorar el rendimiento en todo el ecosistema L2?
• ¿Cómo medimos adecuadamente los escenarios de peor caso cuando algunas de nuestras optimizaciones podrían ser para el caso promedio?
• ¿Cómo gestionamos la tensión entre L1 y L2 que potencialmente pueden divergir?

No tenemos respuestas a muchas de estas preguntas, pero tenemos suficientes pistas iniciales prometedoras para mantenernos ocupados por un tiempo y esperamos ver que estos esfuerzos den frutos en los próximos meses.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [paradigma], Todos los derechos de autor pertenecen al autor original [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 ningún 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.