Dado que Ethereum siguió la hoja de ruta centrada en los rollups, toda la comunidad creía que los rollups serían la solución al problema de escalabilidad de Ethereum. Sin embargo, hasta el día de hoy, los rollups siguen siendo inferiores a algunos L1 de alto rendimiento en términos de potencia de cálculo.

Esto se debe probablemente al hecho de que los equipos de rollups tienen que lidiar no solo con la ejecución, sino también con varios sistemas de prueba, puentes y otras cosas en sus esfuerzos por escalar Ethereum.

Pero tenemos un tipo de rollup que ha surgido para sacar a la luz el verdadero poder de los rollups: los rollups de Gigagas. En nuestra serie anterior, exploramos los rollups basados, los rollups impulsadores y los rollups nativos. En este artículo, examinaremos los rollups de Gigagas al analizar lo que están tratando de resolver y cómo funcionan.

¿Cuáles son los desafíos de rendimiento para rollups?

El problema principal de rendimiento para L2s se ha centrado en el problema de DA. Sin embargo, con los avances recientes en soluciones externas de DA como@eigen_da y la introducción de blobs, DA ya no es el cuello de botella. En cambio, ahora nos encontramos con múltiples nuevas restricciones.

Una de las razones más importantes del problema de rendimiento es que las implementaciones de EVM suelen ser de un solo hilo, lo que significa que utilizan solo un núcleo de CPU a la vez, a pesar de que las CPU modernas tienen múltiples núcleos capaces de manejar diferentes tareas simultáneamente. Como resultado, el límite de rendimiento está determinado por la velocidad de reloj de un solo núcleo.

La transición a la ejecución paralela es compleja debido a los cambios necesarios en el EVM, la gestión del estado y la estructura de transacción. Mientras tanto, investigaciones recientes de @VangelisAndr, demostró que 64.85% de las transacciones de Ethereumpuede ser paralelizado, imagina cuántas transacciones se pueden paralelizar en L2s para aumentar aún más el rendimiento.

Otro desafío surge al aumentar el límite de gas de bloque en L2 para lograr un mayor rendimiento, ya que esto podría comprometer los mecanismos de prueba. Si las pruebas de fraude requieren enviar bloques completos, podrían entrar en conflicto con los límites de tamaño de bloque propios de Ethereum. La producción de bloques L2 difiere de L1, ofreciendo oportunidades de optimización y paralelización en el secuenciador y el cliente de ejecución, alejándose de los conceptos tradicionales de L1.

Un desafío significativo es lograr una secuenciación compartida para mejorar la interoperabilidad de L2 manteniendo la descentralización. Sin embargo, este enfoque sigue siendo novedoso y los rollups principales pueden resistirse a ceder el control de la secuenciación a terceros, ya que los beneficios de una mayor componibilidad no están claros y el rendimiento podría verse afectado.

Ethereum emplea árboles Merkle-Patricia modificados (MPTs) para administrar y verificar sus datos de clave-valor. La EVM no especifica cómo se debe almacenar el estado, lo que permite a los clientes de nodos experimentar con diferentes soluciones. Actualmente, se utilizan implementaciones como LevelDB, PebbleDB y MDBX, pero carecen de las propiedades inherentes de los almacenes de clave-valor autenticados, como las pruebas criptográficas de integridad. Esto aumenta las suposiciones de confianza, complica las pruebas de fraude y agrega sobrecarga a la verificación de los cambios de estado, lo que afecta la eficiencia y la seguridad.

Para la mayoría de los rollups, el rendimiento se mide típicamente por transacciones en lugar de gas. Sin embargo, antes de adentrarnos en cómo los rollups de gigagas abordan los problemas de escalabilidad, exploremos por qué el gas, en lugar de TPS, es una métrica más significativa y por qué deberíamos prestarle atención.

¿Por qué medimos gas?

El rendimiento en rollups y en Ethereum en sí mismo a menudo se mide por Transacciones Por Segundo (TPS), pero una métrica más precisa podría ser 'gas por segundo'. Esta medida indica la capacidad computacional de la red cada segundo, siendo 'gas' el costo computacional de ejecutar operaciones como transacciones o contratos inteligentes.

Sin embargo, TPS pasa por alto la complejidad y las demandas de recursos variables de diferentes transacciones y operaciones, lo que lo convierte en un indicador incompleto y frecuentemente engañoso del rendimiento de la red. Una red puede manejar más transacciones a un costo computacional más bajo, sin embargo, TPS no reflejaría la verdadera capacidad del sistema.

Adoptar el gas por segundo como una métrica de rendimiento estándar proporciona una imagen más clara y precisa de la capacidad y eficiencia de un blockchain. Puedes leer un artículo de @paramonowwsobre por quéTPS es una métrica tonta.

Cuidar el gas es importante porque refleja cuánto trabajo puede manejar la red, proporcionando una imagen más clara de la escalabilidad y eficiencia. La fijación de precios del gas influye en la economía de la red, afectando las tarifas y recompensas de las transacciones, lo que a su vez afecta el comportamiento del usuario y la seguridad de la red. Por lo tanto, aunque las transacciones por segundo dan una visión general, el gas por segundo ofrece una visión más profunda de las verdaderas capacidades de rendimiento de una cadena de bloques.

Ahora que entendemos el gas, ¿qué son específicamente los gigagas y los rollups de gigagas?

¿Qué son los rollups de gigagas?

Gigagas mide el ancho de banda en miles de millones de unidades de gas por segundo, lo que proporciona una medida superior de capacidad que la TPS. Los rollups de Gigagas son básicamente rollups diseñados para gestionar un ancho de banda de 1 gigagas por segundo, procesando 1.000 millones de unidades de gas por segundo. Aunque el concepto es sencillo, su implementación es un desafío. Actualmente, incluso con la secuenciación centralizada, ningún rollup de Ethereum se acerca a este punto de referencia, con todo el ecosistema manejando solo alrededor de 60 Mgas (60 millones de unidades de gas) por segundo.

Fuente:rollup.wtf

Los rollups de Gigagas aumentarían el rendimiento al manejar transacciones en gigagas, lo que permitiría volúmenes de transacciones vastos u operaciones complejas de manera rápida. Mejorarían la eficiencia a través de innovaciones en compresión de datos, generación de pruebas y publicación de datos de la cadena principal, con el objetivo de tener el mínimo costo adicional y el máximo rendimiento.

Varios equipos están desarrollando activamente rollups gigagas. Por ejemplo, @Abundance_xyz está creando toda una pila de rollups de gigagas, mientras que @rise_chainse centra en la construcción de rollups gigagas, introduciendo modificaciones y optimizaciones extensas en el EVM y más allá. Vamos a adentrarnos en cómo funcionan los rollups gigagas, con un énfasis particular en RISE.

¿Cómo funcionan los rollups de gigagas?

RISE es una plataforma L2 diseñada para abordar los problemas de rendimiento de rollups de Ethereum. A pesar de los avances, las soluciones L2 actuales no pueden igualar la velocidad de Solana. RISE utiliza un EVM paralelo, ejecución continua y una nueva arquitectura de estado en RethSDK para aumentar el rendimiento. RISE apunta a un ancho de banda superior a 1 Gigagas por segundo.

La arquitectura de RISE incluye un motor de ejecución EVM paralelo completamente de código abierto llamado pevm, que admite una ejecución continua a través de un pipeline de bloques. Para el acceso al estado, RISE utiliza árboles de Merkle versionados para optimizar el rendimiento y una base de datos personalizada, RiseDB, adaptada para los estados de la cadena EVM.

La pila RISE se construye sobre Reth. En cuanto a la disponibilidad de datos, la arquitectura requiere un ancho de banda alto y es modular para adaptarse a diversas soluciones de disponibilidad de datos. RISE también utiliza la secuencia basada para descentralizar la producción de bloques. Si no sabes qué son los rollups basados, puedes echar un vistazo ael primer artículo de esta serie, que examina sus pros y sus contras.

En configuraciones típicas de la Capa 2, solo alrededor del 8% del tiempo de bloque se gasta en la ejecución debido a un proceso secuencial que implica consenso, ejecución y merklización. Esto se vuelve ineficiente ya que el consenso puede llevar el 40-80% y la merklización hasta el 60% del tiempo restante. El Continuous Block Pipeline (CBP) de RISE mejora esto con una ejecución paralela, procesamiento continuo de transacciones y cálculo simultáneo de la raíz del estado. Esto permite utilizar casi el 100% del tiempo de bloque para la ejecución de transacciones, mejorando significativamente la eficiencia en comparación con los métodos tradicionales.

Ethereum utiliza un sistema de estado de dos capas con un Trie de Merkle Patricia (MPT). El MPT asegura la integridad de los datos, pero conduce a una alta amplificación de lectura y escritura debido a su estructura y la naturaleza del árbol LSM (Log-Structured-Merge) de la base de datos. Esto resulta en numerosas operaciones de E / S para consultas de estado. MPT emplea nodos de extensión para reducir la redundancia, pero los desafíos incluyen el uso ineficiente de SSD, una sobrecarga significativa de compactación y una subutilización de la CPU durante las esperas de E / S.

RISE contrarresta estos problemas mediante el uso de un Árbol de Merkle versionado, que mejora la eficiencia de almacenamiento con claves versionadas. También utiliza el enfoque LETUS con codificación delta y archivos de registro estructurados para reducir los efectos de amplificación. Esto resulta en una mejor gestión de almacenamiento y una recuperación de datos más eficiente.

¿Se convertirá cada rollup en un rollup gigagas?

Hay muchas razones por las cuales no todos los rollups se convertirán en gigagas rollups. No todas las aplicaciones requieren un rendimiento tan alto, y la complejidad y el costo asociados con la tecnología gigagas podrían no estar justificados para proyectos con necesidades de transacciones más bajas o casos de uso más simples.

Algunos rollups priorizan otros aspectos como la facilidad de uso, la privacidad o aplicaciones específicas del sector sobre la simple capacidad de procesamiento. También está el equilibrio entre escalabilidad y descentralización, donde algunos prefieren mantener una estructura más descentralizada en lugar de buscar un rendimiento gigagas. La escalabilidad incremental puede ser más práctica, evitando la necesidad de cambios extensos en el sistema.

Moverse a niveles gigagas podría interrumpir las integraciones existentes o complicar las interacciones del usuario sin necesidad. La elección de convertirse en un rollup gigagas depende en gran medida de los recursos, los objetivos estratégicos y la posición general de la cadena.

Conclusión

Los rollups de gigagas representan un avance significativo en el viaje de escalabilidad de Ethereum al introducir varias mejoras en el stack de rollup. Con estas nuevas características, los rollups de gigagas abordan cuellos de botella fundamentales como la ejecución de un solo hilo, la gestión de merkleización y las ineficiencias de almacenamiento de estado que actualmente enfrentan los rollups L2 tradicionales.

Sin embargo, lograr un rendimiento a nivel de gigagas requiere un cambio arquitectónico relativamente complejo y transformador. Además, implica compensaciones, como el equilibrio entre escalabilidad y descentralización. Como resultado, no es necesario que cada rollup en el ecosistema sea un rollup de Gigagas.

Aparte de todo esto, parece que los rollups de gigagas proporcionarán grandes oportunidades para que la comunidad de Ethereum demuestre el verdadero poder de Ethereum.

A lo largo de esta serie de rollups, hemos profundizado en los diferentes tipos de escalado de Ethereum: desdebasados en rollups en la Parte Iarefuerzos rollups en Parte II,rollups nativos en la Parte III, y finalmente gigagas rollups en esta parte final. Este artículo concluye nuestra exploración de rollups, pero está lejos de ser el final del viaje. ¡Manténgase atento a nuevas series y artículos detallados sobre las últimas innovaciones que dan forma al futuro de Ethereum!

Renuncia:

1. Este artículo es una reproducción de [2077 Investigación]. Todos los derechos de autor pertenecen al autor original [2077 Investigación]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente 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 aprendizaje de gate. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.