Panorama de la computación paralela en Web3: el camino hacia la ruptura de rendimiento de las cadenas compatibles con EVM

Mapa panorámico de la pista de computación paralela Web3: ¿la mejor solución de escalado nativo?

El "trilema de la blockchain" (Blockchain Trilemma) de la blockchain, que incluye "seguridad", "descentralización" y "escalabilidad", revela el compromiso esencial en el diseño de sistemas de blockchain, es decir, que es difícil para los proyectos de blockchain lograr simultáneamente "máxima seguridad, participación universal y procesamiento rápido". En cuanto a la "escalabilidad", este eterno tema, las soluciones de escalado de blockchain más populares en el mercado se clasifican según paradigmas, que incluyen:

  • Ejecución de escalabilidad mejorada: mejora de la capacidad de ejecución en el lugar, como paralelismo, GPU, múltiples núcleos.
  • Escalado de aislamiento de estado: particionamiento horizontal del estado/Sharding, como fragmentos, UTXO, múltiples subredes
  • Escalado tipo outsourcing fuera de la cadena: llevar la ejecución fuera de la cadena, por ejemplo Rollup, Coprocesador, DA
  • Escalabilidad de desacoplamiento estructural: modularidad de la arquitectura, operación colaborativa, por ejemplo, cadena de módulos, ordenadores compartidos, Rollup Mesh
  • Escalado asíncrono y concurrente: modelo Actor, aislamiento de procesos, impulsado por mensajes, por ejemplo, agentes, cadenas asíncronas multihilo.

Las soluciones de escalabilidad de blockchain incluyen: cálculo paralelo en la cadena, Rollup, fragmentación, módulo DA, estructura modular, sistema Actor, compresión de pruebas zk, arquitectura Stateless, entre otros, abarcando múltiples niveles de ejecución, estado, datos y estructura, formando un sistema completo de escalabilidad "multicapa colaborativa y combinación modular". Este artículo se centra en las formas de escalabilidad con cálculo paralelo como corriente principal.

Cálculo paralelo dentro de la cadena (intra-chain parallelism), enfocado en la ejecución paralela de transacciones/instrucciones dentro del bloque. Según el mecanismo de paralelismo, sus métodos de escalabilidad se pueden dividir en cinco grandes categorías, cada una representando diferentes objetivos de rendimiento, modelos de desarrollo y filosofías de arquitectura, donde cada vez el nivel de granularidad del paralelismo es más fino, la intensidad del paralelismo es mayor, la complejidad de la programación también aumenta, y la dificultad de implementación se vuelve cada vez más alta.

  • Paralelismo a nivel de cuenta (Account-level): representa el proyecto Solana
  • Paralelismo a nivel de objeto: representa el proyecto Sui
  • Paralelismo a nivel de transacción (Transaction-level): representa el proyecto Monad, Aptos
  • Llamada de nivel / Micro VM en paralelo (Call-level / MicroVM): representa el proyecto MegaETH
  • Paralelismo a nivel de instrucción (Instruction-level): representa el proyecto GatlingX

Modelo de concurrencia asíncrona fuera de la cadena, representado por el sistema de entidades Actor (Modelo de Agente/Actor), que pertenece a otro paradigma de cálculo paralelo. Como sistema de mensajes intercadena/asíncronos (modelo de no sincronización de bloques), cada Agente funciona como un "proceso inteligente independiente", manejando mensajes asíncronos y eventos de manera paralela, sin necesidad de programación de sincronización. Los proyectos representativos incluyen AO, ICP, Cartesi, entre otros.

Y las soluciones de escalado que conocemos bien, como Rollup o fragmentación, pertenecen a mecanismos de concurrencia a nivel de sistema y no a la computación paralela dentro de la cadena. Logran la escalabilidad a través de "ejecutar múltiples cadenas/dominios de ejecución en paralelo", en lugar de aumentar la paralelización dentro de un solo bloque/máquina virtual. Este tipo de soluciones de escalado no es el enfoque principal de este artículo, pero aún así las utilizaremos para comparar las similitudes y diferencias en la arquitectura.

Mapa panorámico de la pista de computación paralela Web3: ¿la mejor solución para la expansión nativa?

Dos, cadena de mejora paralela EVM: rompiendo los límites de rendimiento en la compatibilidad.

La arquitectura de procesamiento en serie de Ethereum ha evolucionado hasta hoy, pasando por múltiples intentos de escalado que incluyen fragmentación, Rollup y arquitecturas modularizadas, pero el cuello de botella en el rendimiento de la capa de ejecución aún no ha sido superado de manera fundamental. Sin embargo, al mismo tiempo, EVM y Solidity siguen siendo las plataformas de contratos inteligentes con la base de desarrolladores y potencial ecológico más fuerte en la actualidad. Por lo tanto, la cadena de mejora paralela EVM se está convirtiendo en una dirección clave para la evolución de la escalabilidad, equilibrando la compatibilidad ecológica y la mejora del rendimiento de ejecución. Monad y MegaETH son los proyectos más representativos en esta dirección, construyendo arquitecturas de procesamiento paralelo EVM orientadas a escenarios de alta concurrencia y alto rendimiento, cada uno desde la ejecución diferida y la descomposición del estado.

Análisis del mecanismo de cálculo paralelo de Monad

Monad es una cadena de bloques de alto rendimiento Layer1 rediseñada para la máquina virtual de Ethereum (EVM), basada en el concepto fundamental de procesamiento en paralelo (Pipelining), con ejecución asíncrona en la capa de consenso (Asynchronous Execution) y ejecución paralela optimista en la capa de ejecución (Optimistic Parallel Execution). Además, en la capa de consenso y almacenamiento, Monad introduce protocolos BFT de alto rendimiento (MonadBFT) y un sistema de base de datos especializado (MonadDB), logrando una optimización de extremo a extremo.

Pipelining: Mecanismo de ejecución paralela de múltiples etapas

El Pipelining es el concepto básico de la ejecución paralela de Monads. Su idea central es descomponer el flujo de ejecución de la cadena de bloques en múltiples etapas independientes y procesar estas etapas en paralelo, formando una arquitectura de tuberías tridimensional. Cada etapa se ejecuta en hilos o núcleos independientes, logrando un procesamiento concurrente entre bloques, y finalmente alcanzando un aumento en el rendimiento y una reducción en la latencia. Estas etapas incluyen: Propuesta de transacción (Propose), logro de consenso (Consensus), ejecución de transacciones (Execution) y compromiso de bloques (Commit).

Ejecución Asincrónica: Consenso - Desacoplamiento de Ejecución Asíncrona

En la cadena tradicional, el consenso y la ejecución de las transacciones suelen ser procesos síncronos, y este modelo secuencial limita gravemente la escalabilidad del rendimiento. Monad logra la asincronía en la capa de consenso, la capa de ejecución y el almacenamiento a través de "ejecución asíncrona". Esto reduce significativamente el tiempo de bloque y la latencia de confirmación, haciendo que el sistema sea más resiliente, con procesos más segmentados y una mayor eficiencia en la utilización de recursos.

Diseño central:

  • El proceso de consenso (capa de consenso) solo se encarga de ordenar las transacciones y no ejecuta la lógica de los contratos.
  • El proceso de ejecución (capa de ejecución) se activa de forma asíncrona después de que se complete el consenso.
  • Una vez que se complete el consenso, entra inmediatamente en el proceso de consenso del siguiente bloque, sin necesidad de esperar a que se complete la ejecución.

Ejecución Paralela Optimista:乐观并行执行

Ethereum tradicional utiliza un modelo de ejecución serial estricto para evitar conflictos de estado. En cambio, Monad adopta una estrategia de "ejecución paralela optimista", lo que aumenta significativamente la tasa de procesamiento de transacciones.

Mecanismo de ejecución:

  • Monad ejecutará de manera optimista todas las transacciones en paralelo, asumiendo que la mayoría de las transacciones no tienen conflictos de estado.
  • Ejecutar simultáneamente un "Detección de Conflictos (Conflict Detector))" para monitorear si las transacciones acceden al mismo estado (como conflictos de lectura/escritura).
  • Si se detecta un conflicto, las transacciones en conflicto se volverán a ejecutar de forma secuencial para garantizar la corrección del estado.

Monad eligió un camino compatible: modificar lo menos posible las reglas de EVM, logrando la paralelización durante el proceso de ejecución mediante la escritura diferida de estados y la detección dinámica de conflictos, más parecido a una versión de alto rendimiento de Ethereum. Su buena madurez facilita la migración del ecosistema EVM, siendo un acelerador de paralelización en el mundo EVM.

Mapa panorámico del sector de computación paralela en Web3: ¿la mejor solución para la escalabilidad nativa?

Análisis del mecanismo de cálculo paralelo de MegaETH

A diferencia de la ubicación L1 de Monad, MegaETH se posiciona como una capa de ejecución modular de alto rendimiento y compatible con EVM, que puede funcionar tanto como una cadena pública L1 independiente como una capa de mejora de ejecución en Ethereum o como un componente modular. Su objetivo de diseño central es descomponer la lógica de cuentas, el entorno de ejecución y el estado en unidades mínimas que se pueden programar de forma independiente, para lograr una ejecución de alta concurrencia y una capacidad de respuesta de baja latencia dentro de la cadena. La clave de la innovación propuesta por MegaETH radica en: arquitectura Micro-VM + DAG de dependencia de estado (grafo dirigido acíclico de dependencia de estado) y mecanismo de sincronización modular, que en conjunto construyen un sistema de ejecución paralela orientado a "hilos dentro de la cadena".

Arquitectura Micro-VM: cuenta como hilo

MegaETH ha introducido un modelo de ejecución de "una Micro-Virtual Machine (Micro-VM) por cuenta", que "hilo" el entorno de ejecución, proporcionando la unidad de aislamiento mínima para la programación paralela. Estas VM se comunican entre sí a través de mensajes asíncronos (Asynchronous Messaging), en lugar de llamadas síncronas, lo que permite que muchas VM se ejecuten de manera independiente y almacenen de manera independiente, de forma naturalmente paralela.

Dependencia del Estado DAG: mecanismo de programación impulsado por gráficos de dependencia

MegaETH ha construido un sistema de programación DAG basado en relaciones de acceso al estado de la cuenta, que mantiene en tiempo real un gráfico de dependencias global (Dependency Graph). Cada transacción modela las cuentas que se modifican y las que se leen como relaciones de dependencia. Las transacciones sin conflictos pueden ejecutarse directamente en paralelo, mientras que las transacciones con relaciones de dependencia se programarán en orden topológico de forma secuencial o se retrasarán. El gráfico de dependencias asegura la consistencia del estado y la no escritura duplicada durante el proceso de ejecución paralela.

Ejecución asíncrona y mecanismo de devolución de llamada

B

En resumen, MegaETH rompe con el modelo de máquina de estado de un solo hilo tradicional de EVM, implementando un encapsulamiento de micro máquinas virtuales a nivel de cuentas, programando transacciones a través de un gráfico de dependencias de estado y reemplazando la pila de llamadas sincrónicas con un mecanismo de mensajes asíncronos. Es una plataforma de computación paralela rediseñada en todas las dimensiones desde "estructura de cuentas → arquitectura de programación → flujo de ejecución", proporcionando un nuevo enfoque de nivel paradigmático para construir sistemas en cadena de alto rendimiento de próxima generación.

MegaETH eligió un camino de reestructuración: abstraer completamente las cuentas y contratos en una VM independiente, liberando el máximo potencial de paralelismo a través de la programación de ejecución asíncrona. En teoría, el límite de paralelismo de MegaETH es más alto, pero también es más difícil de controlar en términos de complejidad, más parecido a un sistema operativo superdistribuido bajo la filosofía de Ethereum.

Mapa panorámico de la pista de cálculo paralelo de Web3: ¿la mejor solución para la expansión nativa?

La filosofía de diseño de Monad y MegaETH es bastante diferente de la fragmentación (Sharding): la fragmentación divide la blockchain horizontalmente en varias subcadenas independientes (fragmentos Shards), cada subcadena es responsable de parte de las transacciones y el estado, rompiendo las limitaciones de una sola cadena en la expansión a nivel de red; mientras que Monad y MegaETH mantienen la integridad de la cadena única, expandiéndose horizontalmente solo en la capa de ejecución, optimizando la ejecución paralela extrema dentro de la cadena única para superar el rendimiento. Ambos representan dos direcciones en el camino de expansión de la blockchain: el refuerzo vertical y la expansión horizontal.

Los proyectos de computación paralela como Monad y MegaETH se centran principalmente en la optimización del rendimiento, con el objetivo principal de mejorar el TPS en la cadena, logrando el procesamiento paralelo a nivel de transacción o cuenta a través de la ejecución diferida (Deferred Execution) y la arquitectura de micromáquinas virtuales (Micro-VM). Pharos Network, como una red de blockchain L1 modular y de pila completa, tiene un mecanismo de computación paralela central conocido como "Rollup Mesh". Esta arquitectura, a través del trabajo conjunto de la red principal y las redes de procesamiento especializadas (SPNs), admite entornos de múltiples máquinas virtuales (EVM y Wasm), e integra tecnologías avanzadas como pruebas de conocimiento cero (ZK) y entornos de ejecución confiables (TEE).

Análisis del mecanismo de cálculo paralelo Rollup Mesh:

  1. Procesamiento de tuberías asíncronas de ciclo de vida completo (Full Lifecycle Asynchronous Pipelining): Pharos desacopla las diversas etapas de la transacción (como consenso, ejecución, almacenamiento) y utiliza un enfoque de procesamiento asíncrono, lo que permite que cada etapa se lleve a cabo de manera independiente y en paralelo, mejorando así la eficiencia general del procesamiento.
  2. Ejecución Paralela de Doble Máquina Virtual (Dual VM Parallel Execution): Pharos admite dos entornos de máquina virtual, EVM y WASM, lo que permite a los desarrolladores elegir el entorno de ejecución adecuado según sus necesidades. Esta arquitectura de doble VM no solo mejora la flexibilidad del sistema, sino que también incrementa la capacidad de procesamiento de transacciones a través de la ejecución paralela.
  3. Redes de Procesamiento Especial (SPNs): Los SPNs son componentes clave de la arquitectura Pharos, similares a subredes modularizadas, diseñados específicamente para manejar tipos específicos de tareas o aplicaciones. A través de los SPNs, Pharos puede lograr la asignación dinámica de recursos y el procesamiento paralelo de tareas, lo que mejora aún más la escalabilidad y el rendimiento del sistema.
  4. Consenso modular y mecanismo de restaking (Modular Consensus & Restaking): Pharos introduce un mecanismo de consenso flexible que soporta múltiples modelos de consenso (como PBFT, PoS, PoA), y a través del protocolo de restaking (Restaking) logra la conexión entre la mainnet y los SPNs.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
  • Recompensa
  • 7
  • Compartir
Comentar
0/400
just_another_fishvip
· hace23h
¿Quién puede explicar cuál de estas opciones de escalado es más confiable?
Ver originalesResponder0
StableNomadvip
· hace23h
lmao el mismo viejo fud del trilema... solana ya resolvió esto en 2021 para ser sincero
Ver originalesResponder0
OptionWhisperervip
· hace23h
Esta ola de tontos no lo entiende.
Ver originalesResponder0
NftMetaversePaintervip
· hace23h
en realidad, la belleza algorítmica de la ejecución paralela está gravemente subestimada en este discurso del trilema... *ajusta el monóculo digital*
Ver originalesResponder0
SchrodingersPapervip
· hace23h
Ya ha pasado tanto tiempo y todavía estamos debatiendo sobre la expansión, al final el alcista decidirá.
Ver originalesResponder0
LiquidityHuntervip
· hace23h
Parece que la expansión de GPU es un poco interesante.
Ver originalesResponder0
RektRecordervip
· hace23h
Unholy Trinity aún se puede exagerar, ¿no se puede crear algo más?
Ver originalesResponder0
Opere con criptomonedas en cualquier momento y lugar
qrCode
Escanee para descargar la aplicación Gate
Comunidad
Español
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)