Fuente del texto: Gravity

Introducción

Desde el lanzamiento de Gravity Alpha Mainnet en agosto de 2024, la red ha procesado más de 275 millones de transacciones, alcanzando un volumen diario de hasta 2.6 millones de transacciones, y logrando con éxito tarifas de transacción de 30 millones de G. Con la publicación del Litepaper, estamos entusiasmados con el futuro de esta cadena EVM de alto rendimiento. Este documento analizará en profundidad el Litepaper, revelando cómo Gravity está construyendo una arquitectura de cadena de bloques Layer-1 excepcional para aplicaciones del mundo real.

Gravity es una cadena de bloques Layer-1 de alto rendimiento y compatible con EVM creada por Galxe. El desarrollo de Gravity surge de las necesidades de crecimiento de Galxe. La plataforma Galxe, como la mayor plataforma de distribución en cadena del mundo, conecta un vasto ecosistema multichain, atrayendo a más de 25 millones de usuarios. En su proceso de evolución, Galxe se ha convertido en una superaplicación descentralizada que integra herramientas innovadoras como Quest, Passport, Score, Compass y Alva, mientras proporciona servicios ricos como puntos de fidelidad, NFTs de eventos, recompensas de tokens, verificación zk-identidad y ahorros inteligentes entre cadenas. A medida que continúa evolucionando, el alto volumen de transacciones de Galxe se convierte en un factor impulsor clave para la construcción de Gravity: su sistema de puntos de fidelidad soporta 51.2 transacciones por segundo, y las actividades de recompensas de tokens soportan 32.1 transacciones por segundo. Esto nos llevó a tener que migrar a una cadena de bloques EVM al descentralizar el backend de Galxe, mientras mantenemos la mejor experiencia para el usuario.

A medida que Galxe avanza hacia una plena cadena de bloques, se anticipa un aumento adicional en el volumen de transacciones. Se espera que la demanda de rendimiento alcance los 50 millones de gas por segundo, mientras que satisfacer necesidades ecológicas más amplias (como liquidaciones entre cadenas, transacciones de puntos de fidelidad y mercados de NFT) puede requerir una capacidad de procesamiento de 500 millones de gas por segundo. Con esto en mente, el objetivo de Gravity es respaldar un rendimiento de 1 gigagas por segundo para satisfacer las necesidades de escalamiento de aplicaciones intensivas en recursos.

Entre las soluciones existentes, muchas plataformas logran escalabilidad a través de Ethereum, pero los períodos de desafío de L2 Rollup inevitablemente causan retrasos en las transacciones, lo que no es amigable para aplicaciones como Galxe que requieren confirmaciones instantáneas de transacciones. Aunque algunas DApps intentan compensar los retrasos mediante modos de confianza o monitoreo externo, estos métodos introducen complejidades y riesgos adicionales, lo que no es ideal para escenarios de aplicación centrales.

En este contexto, Surge Gravity. Gravity se centra en un EVM paralelo, desarrollando Grevm, el sistema de ejecución EVM paralelo de código abierto más rápido actualmente, reduciendo la brecha de rendimiento entre L2 y L1. Además, Gravity modulariza la arquitectura de Aptos, integrando componentes verificados como Quorum Store y el motor de consenso AptosBFT. Aprovechando la arquitectura madura de AptosBFT, Gravity evita la complejidad y los riesgos potenciales de desarrollar desde cero. Finalmente, Gravity no solo construyó una cadena de bloques L1 de alto rendimiento que ofrece una experiencia de cadena completa, sino que también lanzó el primer SDK de cadena de bloques de tuberías, simplificando enormemente los flujos de interacción entre desarrolladores y usuarios.

Gravity ofrece escalabilidad, capacidad de descentralización y velocidad de transacción casi instantánea sin precedentes. Su tecnología combina las ventajas de L1 y L2, logrando 10,000 transacciones por segundo y confirmaciones en subsegundos. Al mismo tiempo, mediante la integración de protocolos de restaking como EigenLayer y Babylon, Gravity no solo asegura una sólida seguridad en la fase de lanzamiento, sino que también disminuye el riesgo sistémico de depender a largo plazo de un solo activo.

En el futuro, Gravity avanzará de acuerdo a la siguiente hoja de ruta:

· Lanzar la fase 1 de Devnet, probar el rendimiento en tiempo real;

· Lanzar Longevity Testnet, validar la estabilidad a largo plazo de la red;

· Transición de Gravity Alpha Mainnet a Gravity Mainnet completamente operativo, sentando las bases para la aplicación a gran escala de tecnología descentralizada.

A continuación se presenta la compilación completa del Gravity Litepaper.

Resumen

Gravity es una cadena de bloques Layer-1 de alto rendimiento y compatible con EVM creada por Galxe, diseñada para aplicaciones a gran escala y un ecosistema multichain. Sus características incluyen un rendimiento de 1 gigagas por segundo, confirmaciones finales de transacciones en subsegundos y un mecanismo de consenso PoS basado en protocolos de restaking. El diseño de Gravity se basa en dos componentes de código abierto clave: (1) Gravity SDK, que es un motor de consenso de PoS basado en AptosBFT de tuberías; (2) Gravity reth, una capa de ejecución impulsada por Grevm (EVM de Gravity). Estas herramientas proporcionan la capacidad de construir cadenas de bloques alternativas Layer-1 y Layer-2 eficientes para aplicaciones Web3, destacándose especialmente en cadenas EVM. Este documento explora en profundidad el diseño ingenieril e innovaciones tecnológicas de Gravity, mostrando cómo satisfacer necesidades de alto rendimiento a través de arquitecturas de tuberías, algoritmos de consenso avanzados, técnicas de ejecución paralela y mecanismos de almacenamiento optimizados (mejorando reth y refinando el motor de consenso de Aptos).

Introducción

El desarrollo de Gravity surge de los desafíos enfrentados por Galxe en su operación. Galxe es una aplicación Web3 líder que proporciona a los usuarios servicios como puntos de fidelidad, NFTs de eventos, recompensas de tokens, verificación de identidad mediante conocimiento cero y ahorros inteligentes multichain. A medida que Galxe se desarrolla rápidamente, su sistema de puntos de fidelidad procesa un promedio de 51.2 transacciones por segundo, y las actividades de recompensas de tokens procesan un promedio de 32.1 transacciones por segundo. En el proceso de descentralización gradual de Galxe, la migración de estos casos de uso a una cadena de bloques EVM, mientras se asegura una experiencia de usuario fluida, se convierte en un desafío. Por lo tanto, se vuelve crucial desarrollar una cadena de bloques EVM de alto rendimiento que pueda cumplir con (1) un alto rendimiento de transacciones y (2) confirmaciones de transacciones casi instantáneas.

En este contexto, elegir soluciones Layer-2 existentes o desarrollar una nueva Layer-1 es un punto de decisión clave. Layer-1 logra la finalización a través de algoritmos de consenso, mientras que Layer-2 aborda el problema mediante protocolos Rollup. Ambas tienen compromisos: Layer-1 generalmente sacrifica parte del rendimiento debido a las limitaciones del algoritmo de consenso, pero puede lograr una confirmación final de transacciones más rápida. Por ejemplo, el algoritmo de consenso basado en AptosBFT puede confirmar transacciones en subsegundos, mientras que un Rollup optimista puede tener un período de desafío de hasta siete días. Aunque las pruebas de conocimiento cero pueden acelerar este proceso, la confirmación final aún puede tardar horas. Dada la necesidad de Gravity de una confirmación final en subsegundos (especialmente para su protocolo de intención de cadena completa), elegimos construir Layer-1.

Aunque Layer-2 tiene ventajas nativas en la comunicación con Ethereum, Layer-1 como Gravity puede lograr una profunda interoperabilidad con Ethereum y otras cadenas de bloques a través del protocolo de intención de Gravity y puentes entre cadenas. Este diseño no solo colabora de manera fluida con Ethereum, sino que también mejora la conectividad de todo el ecosistema Web3.

Además, los protocolos de restaking (restaking) reducen significativamente la dificultad de construir una cadena de bloques PoS Layer-1. Gravity integra activos apostados de Ethereum y Bitcoin, así como su extensa red de validadores, a través de protocolos como EigenLayer y Babylon. Esto proporciona garantías económicas para el consenso PoS, permitiendo que la descentralización y seguridad de Gravity alcancen niveles comparables a los de Ethereum.

En resumen, Gravity fue diseñado como una cadena de bloques Layer-1 de alto rendimiento y compatible con EVM para satisfacer las necesidades de escalabilidad y rendimiento de aplicaciones Web3 modernas. Aunque su desarrollo inicial se centró en servir a Galxe, la flexibilidad del Gravity SDK y Grevm (EVM de Gravity) lo hace adecuado para construir cualquier Layer-1 y Layer-2 eficiente, similar a Tendermint/Cosmos SDK.

Necesitamos un rendimiento de 1 gigagas/s

Para las cadenas de bloques, el rendimiento es el indicador de rendimiento más crítico, a menudo medido en transacciones por segundo (TPS) o gas por segundo (gas/s). Tomando como ejemplo el sistema de puntos de fidelidad de Galxe, requiere al menos alcanzar 4 millones de gas/s para funcionar de manera estable. Este dato proviene del promedio de 80,000 gas consumidos por cada transacción de puntos de fidelidad, mientras que se pueden procesar aproximadamente 51.2 transacciones por segundo.

Esta predicción está respaldada por datos de la Gravity Alpha Mainnet. Como nuestra red Layer 2 en las pruebas, las transacciones de puntos de fidelidad de Gravity Alpha Mainnet mostraron que su rendimiento puede alcanzar de manera estable 4 millones de gas/s, validando la precisión de las estimaciones anteriores.

Aunque los altos costos de operación en la cadena pueden resultar en una ligera disminución de la demanda, la tendencia de expansión de Galxe muestra que, durante los períodos pico, la demanda podría aumentar dos o tres veces respecto a los niveles actuales. Además, con la inclusión de otros escenarios de aplicación, como NFT, recompensas de tokens, y la futura integración de pruebas de conocimiento cero para tareas en la cadena completa, si Galxe se convierte completamente en una cadena, se espera que la demanda de rendimiento alcance los 50 millones de gas/s. Suponiendo que el uso de gas de las aplicaciones en la cadena Gravity siga una distribución de Pareto (similar a cómo Uniswap consume el 10% del gas de Ethereum), para satisfacer necesidades ecológicas más amplias, como liquidaciones entre cadenas, transacciones de puntos de fidelidad y mercados de NFT, idealmente, el rendimiento debería respaldar 500 millones de gas/s. Por lo tanto, para satisfacer estas demandas potenciales, la cadena de bloques debe ser capaz de procesar 1 gigagas por segundo, asegurando que pueda adaptarse a las necesidades de escalamiento de aplicaciones intensivas en recursos.

Para alcanzar un rendimiento tan alto, es clave introducir una EVM paralela. Hemos desarrollado Grevm, que es el sistema de ejecución EVM paralelo de código abierto más rápido actualmente, y el rendimiento específico se puede ver en capítulos posteriores.

Tiempos de confirmación en subsegundos

Más allá del rendimiento, la velocidad de confirmación de las transacciones es crucial para la experiencia del usuario. Los usuarios modernos están acostumbrados a respuestas casi instantáneas similares a Web2, lo cual sigue siendo un desafío para las cadenas de bloques. Tomemos como ejemplo a Galxe, que es similar a un juego completamente en la cadena y tiene ciertos requisitos de baja latencia. Actualmente, el tiempo de confirmación de transacciones en la mayoría de las cadenas de bloques EVM varía desde unos pocos segundos hasta varios días, lo que está lejos de cumplir con este requisito. Elegimos el algoritmo de consenso AptosBFT para lograr tiempos de confirmación en subsegundos.

Aunque el L2 Rollup puede teóricamente aumentar el rendimiento, sus períodos de desafío provocan retrasos en las transacciones, lo que es muy desfavorable para aplicaciones que requieren confirmaciones instantáneas de transacciones (como Galxe). Si bien algunas DApps intentan optimizar esto a través de modos de confianza o monitoreo externo, esto introduce complejidad y riesgos adicionales, que no son ideales para aplicaciones críticas. Gravity SDK, mediante el diseño de cinco etapas en tuberías, paraleliza los procesos de consenso y ejecución, acortando la brecha de rendimiento entre L2 y L1 (el diseño específico se detalla más adelante).

Seguridad PoS basada en restaking

Gravity SDK proporciona un enfoque seguro para expandir Ethereum, no limitado a L2 Rollup, sino eligiendo una arquitectura L1 protegida por restaking, equilibrando rendimiento, interoperabilidad y seguridad. Los módulos centrales integran protocolos de restaking como EigenLayer y Babylon, proporcionando soporte económico y garantizando un consenso de prueba de participación robusto.

Aprovechando los 45 mil millones de dólares en activos apostados de Ethereum y 850,000 validadores, así como los 600 mil millones de dólares de activos de Bitcoin a través de Babylon, Gravity puede establecer una sólida base de seguridad desde el principio, evitando los problemas comunes de inicio y riesgos de seguridad de las nuevas cadenas de bloques, al mismo tiempo que reduce el riesgo sistémico de depender de un solo activo a largo plazo.

Arquitectura de Gravity Chain

Gravity Chain incluye dos componentes principales: Gravity SDK y Gravity reth. Gravity SDK es un marco de cadena de bloques mejorado de la cadena Aptos, que es actualmente la blockchain PoS más avanzada basada en la familia de algoritmos de consenso HotStuff, cuya arquitectura de tuberías mejora enormemente el rendimiento y la eficiencia de recursos. Gravity reth es la capa de ejecución basada en reth que opera como un reactor de flujo de bloques (BSR) para recibir bloques propuestos de la capa de consenso. Al optimizar reth, Gravity reth logra ejecución paralela, cálculos de compromiso de estado asíncronos por lotes y mejoras en la eficiencia del almacenamiento. Estos dos componentes están estrechamente integrados a través de la interfaz del motor de consenso de Gravity (GCEI) y el adaptador de reth, y son gestionados dinámicamente por el controlador de tuberías en cada etapa.

Este diseño separa la ejecución de bloques del consenso de bloques, haciendo que la capa de ejecución actúe como consumidora de propuestas de bloques. Nuestras optimizaciones en reth permiten que se adapte perfectamente al proceso de propuesta de bloques gestionado por el reactor de flujo de bloques (BSR).

El flujo de transacciones de Gravity Chain es el siguiente:

1. Las transacciones se envían a través de la interfaz JSON RPC de Gravity reth, que es completamente compatible con Ethereum.

2. Posteriormente, las transacciones ingresan al grupo de memoria de Gravity SDK y se propagan a través de la red, donde los validadores procesan las transacciones por lotes y generan un certificado Quorum Store (QS).

3. En cada ronda, el líder presenta una propuesta de bloque que contiene metadatos del bloque y transacciones ordenadas seleccionadas del grupo de memoria y QS.

4. Una vez que la propuesta se marca como ordenada, entra en la capa de ejecución.

5. La capa de ejecución de Grevm procesa transacciones en paralelo, genera resultados de ejecución y transmite el nuevo estado al módulo de gestión de estado.

6. El módulo de estado calcula la raíz de estado y la transmite al motor de consenso para alcanzar un consenso sobre la raíz de estado.

7. Una vez que la raíz de estado se confirma de forma final, el módulo de almacenamiento persiste la raíz de estado y los datos del bloque.

Los siguientes capítulos detallarán cada componente.

Gravity SDK: Práctica innovadora de la cadena de bloques de código abierto en tuberías

Gravity SDK es un marco de cadena de bloques modular de código abierto, desarrollado sobre la cadena de bloques Aptos lista para producción. Su objetivo es modularizar la arquitectura de Aptos, tomando como referencia componentes verificados como Quorum Store y el motor de consenso AptosBFT, para crear el primer SDK de cadena de bloques en tuberías.

Las razones por las que Gravity SDK eligió Aptos como base incluyen:

· Arquitectura tecnológica de vanguardia: Aptos es una avanzada cadena de bloques PoS basada en consenso de la familia HotStuff.

· Rendimiento extremo: Aptos ofrece un rendimiento de 160,000 transacciones por segundo, con tiempos de confirmación finales inferiores a 1 segundo.

· Fiabilidad en la práctica: Aptos ha demostrado una estabilidad y eficiencia sobresalientes tras la validación en entornos de producción.

· Evitar reinventar la rueda: aprovechar la arquitectura madura de Aptos puede evitar la complejidad y los riesgos potenciales de desarrollar desde cero, mientras que otros intentos de superar a Aptos a menudo carecen de teoría y práctica.

· Sinergia: a medida que Aptos continúa evolucionando, Gravity SDK puede integrar sin problemas sus nuevas características, como la API de números aleatorios, mientras que también retroalimenta a Aptos a través de su arquitectura modular y mecanismos de seguridad innovadores.

Las cadenas de bloques basadas en Gravity SDK se conectan al motor de consenso de Gravity (GCEI) a través del motor de consenso en tuberías. Aunque GCEI es compatible con varias capas de ejecución, el Gravity SDK actualmente solo admite Gravity reth. Se discutirán más detalles sobre GCEI en capítulos posteriores.

Interfaz de Consenso de Gravity (GCEI)

El protocolo GCEI (Interfaz de Ejecución de Consenso de Gravity) es el puente de comunicación entre la capa de consenso y la capa de ejecución. Norma la interacción entre las dos capas, asegurando que los procesos de consenso y ejecución se mantengan sincronizados a través del controlador de tuberías.

La principal diferencia entre el SDK de cadenas de bloques tradicionales y Gravity SDK radica en su motor de consenso en tuberías. La capa de ejecución debe implementarse como un reactor de flujo de bloques (Block Stream Reactor), lo que significa que necesita ser capaz de consumir continuamente el flujo de bloques propuestos, y el compromiso de estado debe calcularse de manera asíncrona con la ejecución de transacciones. Además, la capa de ejecución necesita ser capaz de proporcionar señales de retroalimentación a la capa de consenso para ajustar dinámicamente el ritmo de propuesta de bloques.

Además, debido a la naturaleza de tuberías de Gravity SDK, la capa de ejecución debe poder manejar transacciones no ejecutables en bloques propuestos, ya que el grupo de memoria no puede verificar estrictamente la validez de ninguna transacción debido a que no tiene acceso al estado mundial más reciente: la ejecución puede no haber terminado aún. Al mismo tiempo, el resultado de la ejecución no debe bloquear la generación de bloques posteriores, ya que después de que Gravity SDK paraleliza el consenso de bloques con el consenso de estado, la capa de ejecución se convierte en un reactor del flujo de bloques propuestos, pudiendo devolver los resultados de ejecución libremente en etapas posteriores.

El protocolo GCEI define dos conjuntos de API:

· API de capa de consenso: estas API son implementadas por Gravity SDK para que la capa de ejecución responda a las propuestas de bloques del motor de consenso y presente compromisos de estado.

· API de capa de ejecución: estas API deben ser implementadas por la capa de ejecución. El motor de consenso utilizará estas API para intentar verificar, antes de proponer un bloque, y para fluir el bloque propuesto, y notificará a la capa de ejecución el compromiso de estado final.

Desde la perspectiva del ciclo de vida de las transacciones, el protocolo GCEI define lo siguiente:

1. check_txn (API de capa de ejecución)

· Entrada: recibe una transacción (GTxn) como entrada.

· Salida: devuelve la dirección del remitente de la transacción, nonce y límite de gas.

Uso: este método se utiliza para que el motor de consenso realice intentos de verificación antes de proponer transacciones a un bloque. Este método puede ser llamado múltiples veces para la misma transacción, por ejemplo, cuando la transacción entra en el grupo de memoria, antes de ser propuesta a un bloque y cuando se determina el compromiso de estado.

2. submit_txn (API de capa de consenso)

Entrada: recibe una transacción (GTxn) desde la capa de ejecución.

Salida: devuelve Result<(), indicando si la transacción se agregó con éxito al grupo de memoria.

Uso: la capa de ejecución puede utilizar este método para enviar transacciones al grupo de memoria. El motor de consenso luego propagará la transacción a través de la red y formará un Quorum Store después de recibir un lote de transacciones.

3. recv_ordered_block (API de capa de ejecución)

Entrada: recibe un ordered_block (tipo BlockBatch), que contiene transacciones ordenadas y metadatos de bloques.

Salida: devuelve Result<(), indicando si la capa de ejecución recibió y aceptó con éxito el bloque.

Uso: una vez que el motor de consenso propone un bloque, se envía a la capa de ejecución para que se ejecute la transacción. Este método permite a la capa de ejecución recibir y procesar el bloque propuesto.

4. update_state_commitment (API de capa de consenso)

Entrada: compromiso de estado (StateCommitment) de un bloque específico.

Salida: devuelve Result<(), indicando si el compromiso de estado fue aceptado con éxito por el motor de consenso local.

Uso: una vez que la capa de ejecución calcula el compromiso de estado, lo envía a la capa de consenso para su determinación final, es decir, para alcanzar un consenso ligero de 2f+1 con otros validadores. Si el consenso del compromiso de estado tiene una gran disparidad con el progreso del bloque propuesto, el controlador de tuberías ajustará el ritmo de propuesta de bloques.

5. commit_block_hash (API de capa de ejecución)

Entrada: recibe un conjunto de vectores block_ids, que representan los bloques que deben ser enviados.

Salida: devuelve Result<(), indicando si la operación fue exitosa o no.

Uso: una vez que se determina el compromiso de estado, la capa de consenso notificará a la capa de ejecución que presente el hash del bloque en el almacenamiento de bloques.

Pipeline de Blockchain

Gravity SDK maximiza la utilización de recursos de hardware mediante una arquitectura de tuberías de cinco etapas, logrando así un mayor rendimiento y una menor latencia. Las tuberías ejecutan tareas intercaladas entre diferentes bloques, y el administrador de tuberías utiliza un mecanismo de retroalimentación para asegurar que la cadena de bloques avance de manera constante. Las tres primeras etapas pertenecen a la capa de consenso, mientras que las dos últimas pertenecen a la capa de ejecución.

Cada etapa se explica a continuación:

· Fase 1: Propagación de transacciones: esta fase propaga transacciones de manera eficiente entre validadores, asegurando que las transacciones se incluyan de manera oportuna y confiable durante la construcción de bloques. El diseño desacopla la propagación de transacciones del mecanismo de consenso, siguiendo las ideas de Narwhal & Tusk y Aptos, es decir, que los validadores compartan continuamente lotes de transacciones, utilizando todos los recursos de la red para ejecutarse en paralelo. Cuando un lote de transacciones obtiene 2f+1 firmas de peso (formando PoAv, es decir, prueba de disponibilidad), se asegura que el lote de transacciones sea almacenado por al menos f+1 validadores honestos, de modo que todos los validadores honestos puedan recuperar estas transacciones para su ejecución.

· Fase 2: Ordenación de metadatos de bloques: esta fase establece un orden coherente y reconocido de transacciones y metadatos de bloques dentro de la red. El mecanismo de consenso (AptosBFT) sigue la regla de doble cadena (2-chain rule) para proporcionar bloques tolerantes a fallos bizantinos. Los bloques fluirán posteriormente a la fase de ejecución, preparándose para el procesamiento paralelo.

· Fase 3 (BSR): Ejecución paralela de transacciones: esta fase es parte de la capa de ejecución, donde se ejecutan transacciones en paralelo. Los resultados de la ejecución se transmitirán a la fase de compromiso de estado.

· Fase 4: Compromiso de estado: esta fase completa los cambios de estado generados por la ejecución de transacciones y prepara la determinación final del bloque. El compromiso de estado se calcula de forma asíncrona con la ejecución de transacciones, asegurando que la ejecución del siguiente bloque no se vea obstaculizada por el compromiso de estado del bloque actual.

· Fase 5: Persistencia de estado: esta fase persiste los cambios de estado comprometidos en el almacenamiento de la cadena de bloques. La raíz de estado final y los datos relacionados se almacenan en Gravity Store, que utiliza un motor de almacenamiento altamente optimizado, diseñado para un acceso rápido y confiable. Al mismo tiempo, notifica al grupo de memoria y al Quorum Store limpiar las transacciones que no podrán incluirse en el futuro.

Módulos de Staking y Restaking

Construir una cadena de bloques Layer 1 de prueba de participación (PoS) segura es una tarea compleja, especialmente en el caso de depender únicamente de tokens específicos en la cadena para el staking. Este enfoque puede enfrentar problemas de seguridad económica en las primeras etapas, como la volatilidad del valor del token o la limitada participación de los validadores. Para abordar este problema, Gravity SDK proporciona un módulo flexible de Staking y Restaking, diseñado para mejorar la seguridad de la red mediante mecanismos de staking locales y externos.

Una de las estrategias clave de Gravity SDK es la introducción de protocolos de Restaking como EigenLayer y Babylon. Estos protocolos permiten a los validadores volver a apostar activos de otras redes maduras (como Ethereum y Bitcoin), aprovechando su seguridad existente. Al permitir que los validadores pongan en garantía activos de estas cadenas, Gravity SDK puede mejorar la seguridad económica de la red sin depender completamente de tokens locales. Este enfoque no solo refuerza la robustez de la cadena, sino que también fomenta la diversidad del ecosistema de validadores. El diseño del módulo de Staking se centra en la modularidad, y su componente de Restaking tiene una alta flexibilidad para adaptarse fácilmente a nuevos protocolos de Restaking a medida que evoluciona el ecosistema de la cadena de bloques.

Este módulo no solo admite activos de Restaking, sino que también permite el staking de tokens ERC20 personalizados en cadenas que lo soportan, como el G Token en Ethereum. Los validadores pueden participar en el consenso a través del staking de estos tokens permitidos, contribuyendo así a la seguridad de la red. El poder de voto de los validadores se calcula en función de su valor total apostado, que incluye tokens personalizados y activos en el protocolo de restaking. Este cálculo se realiza de acuerdo con la configuración específica de la cadena, asegurando que cada cadena pueda establecer de manera flexible las reglas de staking y restaking según sus necesidades.

El administrador de Epoch en el motor de consenso colabora directamente con el módulo de Staking para calcular el peso del conjunto de validadores para la siguiente ronda. Asegura que el proceso de consenso refleje con precisión las dinámicas de staking más recientes al obtener el valor apostado desde la capa de ejecución. En esta arquitectura, los activos entre cadenas (como los activos apostados provenientes de Ethereum) deben ser primero puenteados a la capa de ejecución antes de poder ser utilizados para calcular el valor total apostado de los validadores. La implementación del mecanismo de puente es responsabilidad de la capa de ejecución, lo que permite tratar la comunicación entre cadenas de manera más flexible. Las posibles soluciones incluyen puentes PoS, pruebas de conocimiento cero del estado de la cadena y mensajería cruzada de auto-arranque incrustada.

Más detalles técnicos, diseño de API y una explicación completa de los mecanismos de Staking y Restaking se presentarán en documentos posteriores.

Gravity Reth: capa de ejecución EVM del reactor de flujo de bloques

La integración de la capa de ejecución de la máquina virtual de Ethereum (EVM) en la arquitectura de Gravity SDK presenta desafíos únicos, especialmente al aprovechar al máximo las capacidades de su motor de consenso en tuberías. Para lograr una integración fluida y maximizar el potencial de esta arquitectura, necesitamos realizar varias optimizaciones clave en el cliente de Ethereum de código abierto reth. Estas optimizaciones transforman fundamentalmente a reth en Gravity reth, una capa de ejecución EVM optimizada para motores de consenso en tuberías.

Las arquitecturas de cadenas de bloques tradicionales procesan bloques de manera secuencial, asegurando que cada bloque esté completamente validado y ejecutado antes de proponer el siguiente bloque. Sin embargo, Gravity SDK adopta un mecanismo de consenso de tuberías que separa las diversas etapas del procesamiento de bloques para mejorar el rendimiento. Este cambio de paradigma introduce complejidades:

Transacciones inesperadas: en la cadena de bloques de tuberías, dado que la ejecución del bloque anterior puede no haberse completado, el grupo de memoria no puede acceder al estado mundial más reciente. Por lo tanto, las transacciones incluidas en el bloque propuesto pueden no ejecutarse en el momento de la propuesta, ya que su validez no puede ser verificada estrictamente sin el estado más reciente.

Resultados de ejecución no bloqueantes: para evitar estancamientos en las tuberías, los resultados de ejecución no deben bloquear la generación de bloques posteriores. La capa de ejecución debe ser capaz de procesar bloques propuestos de manera asíncrona y devolver los resultados de ejecución en etapas posteriores sin obstaculizar el proceso de consenso. Para EVM, esto significa que es necesario redefinir blockhash, eliminando la dependencia del campo stateRoot en el encabezado del bloque.

Para abordar estos problemas, hemos introducido cuatro optimizaciones clave:

· Reactor de flujo de bloques (Block Stream Reactor, BSR): el BSR tiene como objetivo adaptar reth al flujo de propuestas de bloques de Gravity SDK. Permite que la capa de ejecución consuma continuamente el flujo de bloques propuestos, actuando como un reactor para procesar bloques de manera asíncrona. El BSR establece un ciclo de retroalimentación dinámico con el motor de consenso, combinando señales de retroalimentación adecuadas. Estas señales ajustan en tiempo real la velocidad de propuesta de bloques y compromiso de estado según el rendimiento y latencia de la capa de ejecución. Si la capa de ejecución se retrasa debido a transacciones complejas o limitaciones de recursos, el mecanismo de retroalimentación reducirá la tasa de propuestas de bloques para asegurar la estabilidad del sistema.

· Desacoplamiento de compromiso de estado y ejecución de transacciones: la segunda optimización implica separar el cálculo del compromiso de estado de la ejecución de transacciones. Al desacoplar estos procesos, logramos la asincronía en el cálculo del compromiso de estado, permitiendo que la ejecución de bloques posteriores no tenga que esperar a que se complete el compromiso de estado del bloque actual. Redefinimos blockhash, eliminando la dependencia del campo stateRoot en el encabezado del bloque, asegurando que el cálculo de la raíz de estado no bloquee la generación de bloques posteriores.

· Optimización de la capa de almacenamiento: en la arquitectura de tuberías, el almacenamiento y la persistencia eficientes de valores de estado de múltiples versiones y la presentación de estado son cruciales. La tercera optimización se centra en mejorar la capa de almacenamiento para satisfacer estas necesidades sin introducir cuellos de botella. Al optimizar el mecanismo de almacenamiento, nos aseguramos de que los datos de estado puedan escribirse rápidamente y ser recuperados de forma concurrente. Esto incluye construir un motor de almacenamiento de múltiples versiones y soportar I/O asíncrono desde la base de datos hasta la API de almacenamiento.

· EVM paralelo: la última optimización implica la ejecución de transacciones en paralelo dentro de la EVM. Hemos desarrollado Grevm, un tiempo de ejecución EVM paralelo que acelera significativamente el procesamiento de transacciones mediante la ejecución concurrente. Grevm aprovecha las pistas de dependencia de datos obtenidas de la simulación de transacciones para optimizar la ejecución paralela, reduciendo la reejecución de transacciones y aumentando el rendimiento.

Grevm (EVM de Gravity) - Ejecución EVM en paralelo

Grevm es un proyecto de código abierto, alojado en GitHub (si aún no está abierto, se abrirá en el futuro). Consulte su README para obtener más información.

Grevm (EVM de Gravity) es un tiempo de ejecución EVM paralelo basado en revm. Los algoritmos de Grevm están inspirados en BlockSTM y se mejoran mediante la introducción de un grafo de dependencia de datos obtenido de simulaciones. Este mecanismo hace que la programación de la ejecución paralela sea más eficiente, minimizando la reejecución de transacciones.

En nuestras pruebas de referencia, Grevm es actualmente la implementación de EVM paralela de código abierto más rápida. Para transacciones sin conflictos, Grevm es 4.13 veces más rápido que la ejecución secuencial, alcanzando una velocidad de 26.50 gigagas/s. Si simulamos un retraso de I/O de 100 μs en el mundo real, su velocidad es 50.84 veces más rápida que la ejecución secuencial, con un rendimiento de 6.80 gigagas/s. Este salto de rendimiento se debe a la integración de la ejecución paralela con operaciones de I/O asíncronas, lo que permite que las operaciones de I/O se superpongan de manera eficiente, acelerando aún más el proceso.

La idea central de Grevm es aprovechar la dependencia de datos entre transacciones para optimizar la ejecución paralela mediante un conjunto de lectura/escritura de transacciones especulativas. Aunque no todas las pistas son completamente precisas, estas pistas basadas en simulaciones suelen ser suficientemente prácticas. Por ejemplo, en la mainnet de Ethereum, según el uso histórico de gas, aproximadamente el 30% de las transacciones son simples transferencias de Ether, y entre el 25% y el 30% son transferencias de tokens ERC20, que normalmente solo implican la lectura y escritura de un número limitado de cuentas y espacios de almacenamiento. Para estas transacciones, los resultados de la simulación tienen una precisión consistente.

Basándonos en estas ideas, desarrollamos un marco de ejecución paralela de tres etapas para Grevm, como un trabajo posterior al modelo Block-STM, combinando las pistas de dependencia de datos obtenidas de la simulación de transacciones:

· Fase 1: Generación de pistas y precarga de estado: en esta fase, se simulan transacciones para recopilar pistas de dependencia y precalentar la caché de memoria. Esta fase se puede ejecutar en diferentes momentos, dependiendo del diseño de la cadena de bloques. Por ejemplo, cuando llegan nuevas transacciones al grupo de memoria, se puede ejecutar la simulación de inmediato para preparar las pistas de dependencia con anticipación.

· Fase 2: Análisis de dependencias: convierte las pistas de dependencia recopiladas durante la fase de simulación en un grafo acíclico dirigido (DAG) que representa las relaciones de dependencia entre transacciones. Este DAG se utiliza para planificar la programación de transacciones en la ejecución paralela posterior.

· Fase 3: Ejecución paralela bajo resolución de conflictos: se utiliza un algoritmo BlockSTM modificado basado en dependencias DAG para ejecutar transacciones en paralelo. El programa de programación ya no elige transacciones estrictamente de acuerdo con el número de secuencia de las transacciones en el bloque (por ejemplo, 1, 2, 3, ..., n), sino que prioriza la selección de transacciones según el orden del DAG, minimizando conflictos y reduciendo la necesidad de reejecución.

Compromiso de estado por lotes asíncrono

La generación del compromiso de estado sigue siendo un cuello de botella clave en la tubería de la cadena de bloques, debido a la naturaleza secuencial de la merkelización. Cada cálculo de subárbol debe completarse antes de que se pueda generar el compromiso de estado final, lo que puede causar retrasos significativos. Aunque las soluciones existentes (como la paralelización a nivel de cuentas de reth) han introducido cierto grado de paralelización, todavía existe un amplio margen para la optimización. En el contexto de la capa de ejecución del reactor de flujo de bloques (BSR) de Gravity reth, el compromiso de estado de consenso y la ejecución de transacciones se desacoplan, permitiendo que el cálculo del compromiso de estado se realice de manera asíncrona y por lotes sin bloquear la ejecución.

Para abordar estos problemas, el marco propuesto introduce las siguientes innovaciones clave:

Cálculo de hash por lotes asíncronos: aprovechando el desacoplamiento del consenso de compromiso de estado y la ejecución de transacciones, este marco logra un cálculo asíncrono del compromiso de estado. La actualización de la raíz de estado se realiza por lotes (por ejemplo, cada 10 bloques) para reducir la frecuencia del cálculo de la raíz de estado. Este enfoque de procesamiento por lotes logra un cálculo de hash eficiente de nodos sucios compartidos, minimizando así los costos de actualización frecuente y reduciendo el costo computacional total. Para bloques pequeños, el procesamiento por lotes puede aumentar significativamente la paralelización; para bloques grandes, puede reducir el costo computacional total.

Completamente paralelizado: este marco extiende la paralelización a todo el árbol de estados, no solo al árbol de cuentas individuales. Para los nodos marcados como 'sucios', el marco utiliza un algoritmo de cálculo de estado paralelo que divide el árbol en subárboles independientes y procesa estos subárboles en paralelo. Los resultados se agregan en la parte superior para calcular eficientemente la raíz final. Este enfoque garantiza que los bloques grandes con numerosas transacciones y cambios de estado puedan aprovechar al máximo el multithreading, maximizando así el rendimiento.

Raíces de estado alternativas rápidas: para adaptarse al encabezado de bloque de Ethereum y a los códigos de operación BLOCKHASH (que requieren acceder a las raíces de estado de los últimos 256 bloques), redefinimos la raíz de estado. En lugar de depender de un compromiso de estado final (que no está disponible durante la ejecución de transacciones), calculamos la raíz de estado como una combinación del conjunto de cambios de bloque con el hash de la raíz de estado anterior. Este enfoque hace que el cálculo de la raíz de estado sea más rápido, sin necesidad de esperar a que se complete el compromiso de estado completo.

Gravity Store

Para satisfacer las demandas de gestión de grandes datos de alto rendimiento de las cadenas de bloques, Gravity Store surge como una capa de almacenamiento de múltiples versiones optimizada. Se basa en el diseño de reth, que ya ha reducido el problema de expansión del estado al separar el almacenamiento de compromiso de estado y el de datos de estado, al tiempo que disminuye los costos de lectura y escritura de datos. Sin embargo, la capa de ejecución de Gravity reth necesita soporte adicional para el procesamiento paralelo y el compromiso de estado asíncrono, lo que plantea más requisitos técnicos.

Para abordar estos desafíos, Gravity Store propone una eficiente estructura de árbol de múltiples versiones, diseñada a medida para nuestra estructura BSR (Block Stream Reactor). Esta estructura de árbol soporta la gestión de actualizaciones de estado de múltiples versiones. A diferencia del enfoque tradicional que actualiza inmediatamente el valor hash después de las modificaciones, Gravity Store marca los nodos modificados como 'nodos sucios', permitiendo así el procesamiento diferido y la ejecución por lotes del cálculo de hashes. Este diseño permite la creación rápida de nuevas versiones, consultas eficientes de datos de versiones específicas y la limpieza de versiones antiguas por debajo de una altura específica, mejorando significativamente el rendimiento de la gestión del estado de la cadena de bloques.

También estamos investigando el desarrollo independiente de un motor de almacenamiento Gravity DB, cuyo objetivo de diseño es proporcionar una capa de almacenamiento optimizada para aplicaciones de cadena de bloques, y soportar operaciones de I/O completamente asíncronas. El diseño de este motor está inspirado en LETUS, un motor de base de datos estructurada de registro de alto rendimiento orientado a cadenas de bloques. Nuestro desarrollador principal, Richard, uno de los principales autores de LETUS, detallará su diseño en una próxima publicación del blog.

Conclusión

Gravity Chain es una cadena de bloques de primera capa compatible con EVM de alto rendimiento, diseñada para satisfacer las necesidades de escalabilidad y rendimiento de aplicaciones web3 modernas. Combinando Gravity SDK, el motor de consenso AptosBFT en tuberías, y la capa de ejecución Gravity reth impulsada por Grevm, Gravity logra un rendimiento de 1 gigagas por segundo, tiempos de confirmación de transacciones en subsegundos, así como seguridad PoS basada en mecanismos de restaking. El diseño de estos componentes tecnológicos proporciona una base sólida para crear cadenas de bloques personalizadas L1 alternativas o soluciones L2 más eficientes, particularmente adecuadas para optimizar escenarios de uso en cadenas EVM.

Este artículo proviene de una presentación, no representa la opinión de BlockBeats.