El "Trilema de la Blockchain" revela las compensaciones esenciales en el diseño de sistemas de blockchain, a saber, la dificultad de lograr "seguridad absoluta, participación universal y procesamiento de alta velocidad" simultáneamente. En cuanto al eterno tema de la "escalabilidad", las soluciones de escalado de blockchain más comunes actualmente en el mercado se pueden clasificar según paradigmas, incluyendo:

• Ejecutar escalabilidad mejorada: Mejore las capacidades de ejecución en el lugar, como paralelismo, GPU y multicore.
• Expansión aislada por estado: particionamiento horizontal del estado / Shard, como sharding, UTXO, multi-subred
• Escalado de externalización fuera de la cadena: ejecución fuera de la cadena, como Rollup, Coprocessor, DA
• Expansión de estructura desacoplada: arquitectura modular, operación colaborativa, como cadenas de módulos, clasificadores compartidos, Rollup Mesh.
• Escalado concurrente asíncrono: modelo de actores, aislamiento de procesos, impulsado por mensajes, como agentes, cadenas asíncronas multihilo.

Las soluciones de escalado de blockchain incluyen: computación paralela en cadena, Rollup, fragmentación, módulos DA, estructuras modulares, sistemas Actor, compresión de pruebas zk, arquitectura sin estado, etc., cubriendo múltiples capas de ejecución, estado, datos y estructura, formando un "sistema de escalado completo de colaboración multicapa y combinación modular". Este artículo se centra en el método de escalado principal basado en computación paralela.

El paralelismo intra-cadena se centra en la ejecución paralela de transacciones/instrucciones dentro del bloque. De acuerdo con el mecanismo paralelo, sus métodos de escalado se pueden dividir en cinco categorías, cada una representando diferentes objetivos de rendimiento, modelos de desarrollo y filosofías arquitectónicas. La granularidad del paralelismo se vuelve más fina, la intensidad del paralelismo aumenta, la complejidad de la programación se eleva, así como también la dificultad de implementación.

• Nivel de cuenta: Representa el proyecto Solana
• Paralelismo a nivel de objeto: representa el proyecto Sui
• Nivel de transacción: Representa los proyectos Monad, Aptos
• Nivel de llamada / MicroVM: Representa el proyecto MegaETH
• Paralelismo a nivel de instrucción: Representa el proyecto GatlingX

El modelo concurrente asíncrono fuera de la cadena, representado por el sistema Actor (Modelo de Agente / Actor), pertenece a otro paradigma de computación paralela. Como un sistema de mensajería entre cadenas / asíncrono (modelo de no bloqueo y sincronización), cada Agente opera como un "proceso agente" que se ejecuta de manera independiente, enviando mensajes asíncronamente de forma paralela, impulsado por eventos y sin necesidad de programación sincronizada. Proyectos notables incluyen AO, ICP, Cartesi, etc.

Las conocidas soluciones de escalabilidad Rollup o sharding pertenecen a mecanismos de concurrencia a nivel de sistema y no se incluyen en la computación paralela en cadena. Logran escalabilidad al "ejecutar múltiples cadenas/dominios de ejecución en paralelo" en lugar de mejorar el paralelismo dentro de un solo bloque/máquina virtual. Tales soluciones de escalabilidad no son el enfoque de este artículo, pero aún las utilizaremos para un análisis comparativo de conceptos arquitectónicos.

2. Cadena Paralela Mejorada basada en EVM: Rompiendo Límites de Rendimiento a través de la Compatibilidad

La arquitectura de procesamiento en serie de Ethereum se ha desarrollado a través de múltiples rondas de intentos de expansión, incluyendo sharding, Rollup y arquitectura modular. Sin embargo, el cuello de botella de rendimiento de la capa de ejecución aún no se ha superado fundamentalmente. Mientras tanto, EVM y Solidity siguen siendo las plataformas de contratos inteligentes más amigables para los desarrolladores y ecológicamente potentes en la actualidad. Por lo tanto, las cadenas mejoradas en paralelo basadas en EVM se están convirtiendo en una dirección importante para la próxima ronda de evolución en 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 respectivamente arquitecturas de procesamiento paralelo de EVM destinadas a escenarios de alta concurrencia y alto rendimiento, comenzando desde la ejecución retrasada y la descomposición del estado.

Análisis del mecanismo de computación paralela de Monad

Monad es una blockchain de Capa 1 de alto rendimiento rediseñada para la Máquina Virtual de Ethereum (EVM), basada en el concepto fundamental paralelo de pipelining, que presenta ejecución asíncrona en la capa de consenso y ejecución paralela optimista en la capa de ejecución. Además, Monad introduce un protocolo BFT de alto rendimiento (MonadBFT) y un sistema de bases de datos dedicado (MonadDB) en las capas de consenso y almacenamiento, logrando optimización de extremo a extremo.

Pipelining: Mecanismo de ejecución paralela de múltiples etapas
El pipelining es el concepto fundamental de la ejecución paralela de Monad. Su idea central es descomponer el proceso de ejecución de la blockchain en múltiples etapas independientes y procesar estas etapas en paralelo, formando una arquitectura de tubería tridimensional. Cada etapa se ejecuta en hilos o núcleos independientes, logrando un procesamiento concurrente entre bloques, mejorando en última instancia el rendimiento y reduciendo la latencia. Estas etapas incluyen: propuesta de transacción (Propose), alcance de consenso (Consensus), ejecución de transacciones (Execution) y compromiso de bloque (Commit).

Ejecución Asincrónica: Consenso - Desacoplamiento Asincrónico
En las blockchains tradicionales, el consenso y la ejecución de transacciones son típicamente procesos sincrónicos, y este modelo serial limita gravemente la escalabilidad del rendimiento. Monad logra una capa de consenso asincrónica, una capa de ejecución asincrónica y un almacenamiento asincrónico a través de "ejecución asincrónica". Esto reduce significativamente el tiempo de bloque y los retrasos en la confirmación, haciendo que el sistema sea más resistente, los flujos de procesamiento más granulares y la utilización de recursos más alta.

Diseño Central:

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

Ejecución Paralela Optimista
Ethereum tradicional utiliza un modelo serial estricto para la ejecución de transacciones para evitar conflictos de estado. En contraste, Monad emplea una estrategia de "ejecución paralela optimista", lo que mejora significativamente la velocidad de procesamiento de transacciones.

Mecanismo de ejecución:

• Monad ejecutará optimistamente todas las transacciones en paralelo, asumiendo que la mayoría de las transacciones no tienen conflictos de estado.
• Al mismo tiempo, ejecute un "Detector de Conflictos" para monitorear si las transacciones están accediendo al mismo estado (como conflictos de lectura/escritura).
• Si se detecta un conflicto, las transacciones en conflicto se serializarán y se volverán a ejecutar para garantizar la corrección del estado.

Monad elige un camino compatible: realizando la menor cantidad de cambios posible en las reglas de EVM, logrando paralelismo al diferir las escrituras de estado y detectar dinámicamente conflictos durante la ejecución, pareciendo una versión de rendimiento de Ethereum. Su madurez facilita la migración fácil del ecosistema EVM y sirve como un acelerador paralelo en el mundo EVM.

Análisis del Mecanismo de Computación Paralela de MegaETH

A diferencia de la posición L1 de Monad, MegaETH se posiciona como una capa de ejecución paralela modular de alto rendimiento compatible con EVM, que puede servir como una cadena pública L1 independiente o como una capa de mejora de ejecución en Ethereum o como un componente modular. Su objetivo de diseño central es aislar y deconstruir la lógica de cuentas, el entorno de ejecución y el estado en unidades mínimas programables de forma independiente para lograr una alta ejecución concurrente y capacidades de respuesta de baja latencia en la cadena. Las principales innovaciones propuestas por MegaETH son: arquitectura Micro-VM + DAG de Dependencias de Estado (Grafos Acíclicos Dirigidos de Dependencias de Estado) y un mecanismo de sincronización modular, que en conjunto construyen un sistema de ejecución paralela orientado hacia "hilos en la cadena."

Arquitectura Micro-VM: La cuenta es un hilo
MegaETH introduce el modelo de ejecución de “una micro máquina virtual (Micro-VM) por cuenta”, que hila el entorno de ejecución y proporciona la unidad de aislamiento más pequeña para la programación paralela. Estas VMs se comunican a través de mensajería asíncrona en lugar de llamadas síncronas, lo que permite que un gran número de VMs se ejecute de manera independiente y almacene de manera independiente, lo que permite un paralelismo natural.

DAG de Dependencia de Estado: Un mecanismo de programación impulsado por gráficos de dependencia
MegaETH ha construido un sistema de programación DAG basado en las relaciones de acceso al estado de las cuentas. El sistema mantiene un Grafo de Dependencias global en tiempo real, modelando qué cuentas son modificadas y cuáles son leídas durante cada transacción como dependencias. Las transacciones no conflictivas pueden ejecutarse en paralelo, mientras que las transacciones con dependencias se programarán en orden o se diferirán de acuerdo con una secuencia topológica. El grafo de dependencias asegura la consistencia del estado y la escritura no repetitiva durante el proceso de ejecución paralela.

Ejecución Asincrónica y Mecanismo de Callback
MegaETH se basa en el paradigma de programación asíncrona, similar al paso de mensajes asíncrono del Modelo Actor, abordando los problemas de las llamadas en serie tradicionales del EVM. Las llamadas a contratos son asíncronas (ejecución no recursiva), y al llamar al contrato A -> B -> C, cada llamada se realiza de forma asíncrona sin bloquear; la pila de llamadas se expande en un gráfico de llamadas asíncrono (Call Graph); el procesamiento de transacciones = recorrer el gráfico asíncrono + resolución de dependencias + programación paralela.

En resumen, MegaETH rompe el modelo tradicional de máquina de estado de un solo hilo de EVM al implementar la encapsulación de micro máquinas virtuales sobre una base de cuenta, programando transacciones a través de un gráfico de dependencia de estado y utilizando un mecanismo de mensajería asíncrono en lugar de una pila de llamadas sincrónicas. Es una plataforma de computación paralela que ha sido rediseñada en todas las dimensiones desde "estructura de cuenta → arquitectura de programación → flujo de ejecución", proporcionando un enfoque nuevo a nivel de paradigma para construir la próxima generación de sistemas en cadena de alto rendimiento.

MegaETH ha elegido un camino de reconstrucción: abstraer completamente cuentas y contratos en una VM independiente, y liberar un potencial paralelo extremo a través de la programación de ejecución asincrónica. Teóricamente, el límite paralelo de MegaETH es más alto, pero también es más difícil controlar la complejidad, asemejándose a un sistema operativo super distribuido bajo el concepto de Ethereum.

Los conceptos de diseño de Monad y MegaETH son bastante diferentes del sharding: el sharding divide horizontalmente la blockchain en múltiples sub-cadenas independientes (shards), siendo cada sub-cadena responsable de una parte de las transacciones y estados, rompiendo las limitaciones de una sola cadena para lograr escalabilidad a nivel de red; mientras que Monad y MegaETH mantienen la integridad de una única cadena y solo logran escalabilidad horizontal a nivel de ejecución, optimizando el rendimiento a través de una ejecución paralela extrema dentro de la única cadena. Los dos representan dos direcciones en el camino de escalabilidad de blockchain: mejora vertical y expansión horizontal.

Proyectos como Monad y MegaETH se centran en caminos de optimización de rendimiento, con el objetivo principal de mejorar el TPS en la cadena. Logran un procesamiento paralelo a nivel de transacción o a nivel de cuenta a través de arquitecturas de Ejecución Diferida y Micro-VM. Pharos Network, como una red blockchain L1 modular y de pila completa, tiene un mecanismo central de computación paralela conocido como "Rollup Mesh". Esta arquitectura admite entornos multi-máquina virtual (EVM y Wasm) a través del trabajo colaborativo de la red principal y las Redes de Procesamiento Especial (SPNs), integrando tecnologías avanzadas como Pruebas de Conocimiento Cero (ZK) y Entornos de Ejecución Confiables (TEE).

Análisis del mecanismo de computación paralela de malla Rollup:

• Ciclo de vida completo de la canalización asíncrona: Pharos desacopla las diversas etapas de una transacción (como consenso, ejecución, almacenamiento) y adopta un enfoque de procesamiento asíncrono, lo que permite que cada etapa avance de manera independiente y en paralelo, mejorando así la eficiencia del procesamiento en general.
• Ejecución Paralela de Doble VM: Pharos admite dos entornos de máquina virtual, EVM y WASM, lo que permite a los desarrolladores elegir el entorno de ejecución apropiado según sus necesidades. Esta arquitectura de doble VM no solo mejora la flexibilidad del sistema, sino que también mejora las capacidades de procesamiento de transacciones a través de la ejecución paralela.
• Redes de Procesamiento Especial (SPNs): Las SPNs son componentes clave en la arquitectura de Pharos, similares a subredes modulares, diseñadas específicamente para manejar tipos específicos de tareas o aplicaciones. A través de las SPNs, Pharos puede lograr una asignación dinámica de recursos y un procesamiento paralelo de tareas, mejorando aún más la escalabilidad y el rendimiento del sistema.
• Consenso Modular y Restaking: Pharos presenta un mecanismo de consenso flexible que admite múltiples modelos de consenso (como PBFT, PoS, PoA) y logra un intercambio seguro y una integración de recursos entre la cadena principal y los SPNs a través del protocolo de Restaking.

Además, Pharos ha reestructurado el modelo de ejecución del motor de almacenamiento subyacente utilizando árboles de Merkle de múltiples versiones, codificación delta, direccionamiento versionado y tecnologías de empuje ADS, lanzando el motor de almacenamiento de alto rendimiento de blockchain nativo Pharos Store, logrando un alto rendimiento, baja latencia y fuertes capacidades de procesamiento verificable en la cadena.

En general, la arquitectura Rollup Mesh de Pharos logra capacidades de computación paralela de alto rendimiento a través de un diseño modular y un mecanismo de procesamiento asíncrono. Pharos actúa como un coordinador de programación para la paralelismo entre Rollups, no como un optimizador de ejecución para el "paralelismo en cadena", sino que se encarga de tareas de ejecución personalizadas heterogéneas a través de SPNs.

Además de la arquitectura de ejecución paralela de Monad, MegaETH y Pharos, también observamos que hay algunos proyectos en el mercado que exploran las vías de aplicación de la aceleración por GPU en la computación paralela de EVM, que sirven como un complemento importante y un experimento de vanguardia para el ecosistema paralelo de EVM. Entre ellos, Reddio y GatlingX son dos direcciones representativas:

• Reddio es una plataforma de alto rendimiento que combina zkRollup y arquitectura de ejecución paralela con GPU. Su núcleo radica en reconstruir el proceso de ejecución de EVM, logrando la paralelización nativa en la capa de ejecución a través de la programación de múltiples hilos, almacenamiento de estado asíncrono y ejecución acelerada por GPU de lotes de transacciones. Pertenece a la granularidad paralela de nivel de transacción + nivel de operación (ejecución de múltiples hilos de opcodes). Su diseño introduce la ejecución por lotes con múltiples hilos, la carga de estado asíncrona y el procesamiento paralelo por GPU de la lógica de transacciones (EVM Paralelo Compatible con CUDA). Al igual que Monad / MegaETH, Reddio también se centra en el procesamiento paralelo en la capa de ejecución, siendo la diferencia la reconstrucción del motor de ejecución a través de una arquitectura paralela con GPU, diseñada específicamente para escenarios de alta capacidad y que requieren intensivos recursos computacionales (como la inferencia de IA). El SDK ha sido lanzado, proporcionando un módulo de ejecución integrable.
• GatlingX afirma ser un "GPU-EVM" y propone una arquitectura más radical que intenta migrar el modelo de "ejecución serial a nivel de instrucción" de la máquina virtual EVM tradicional a un entorno de ejecución paralelo nativo de GPU. Su mecanismo central implica compilar dinámicamente el bytecode de EVM en tareas paralelas de CUDA, ejecutando flujos de instrucciones a través de múltiples núcleos de GPU, rompiendo así el cuello de botella secuencial de la EVM en el nivel más bajo. Pertenece a la granularidad paralela a nivel de instrucción (Instruction-Level Parallelism, ILP). En comparación con la granularidad paralela a "nivel de transacción/nivel de cuenta" de Monad / MegaETH, el mecanismo paralelo de GatlingX está más cerca de las rutas de optimización a nivel de instrucción, más parecido a la reconstrucción subyacente del motor de la máquina virtual. Actualmente, se encuentra en la etapa conceptual, con un documento técnico y bocetos arquitectónicos publicados, pero aún no hay SDK ni mainnet.

Artela propone un concepto de diseño paralelo diferenciado. Al introducir la arquitectura EVM++ con una máquina virtual WebAssembly (WASM), permite a los desarrolladores agregar y ejecutar dinámicamente extensiones en la cadena mientras mantiene la compatibilidad con EVM, utilizando el modelo de programación Aspect. Toma la granularidad de las llamadas a contrato (Función / Extensión) como la unidad paralela mínima, apoyando la inyección de módulos de Extensión (similar a "middleware enchufable") durante el tiempo de ejecución del contrato EVM, logrando desacoplamiento lógico, llamadas asíncronas y ejecución paralela a nivel de módulo. Se centra más en la composabilidad y la arquitectura modular de la capa de ejecución. Este concepto ofrece nuevas ideas para futuras aplicaciones complejas de múltiples módulos.

3. Cadena de Arquitectura Paralela Nativa: Reestructurando la Entidad de Ejecución de la VM

El modelo de ejecución EVM de Ethereum ha adoptado una arquitectura de un solo hilo de "orden total de transacciones + ejecución en serie" desde su diseño, con el objetivo de garantizar la determinación y consistencia de los cambios de estado en todos los nodos de la red. Sin embargo, esta arquitectura tiene cuellos de botella de rendimiento inherentes que limitan el rendimiento y la escalabilidad del sistema. En contraste, las cadenas de arquitectura de computación paralela nativa como Solana (SVM), MoveVM (Sui, Aptos) y Sei v2 construidas sobre Cosmos SDK están diseñadas para la ejecución paralela desde cero, ofreciendo las siguientes ventajas:

• El modelo de estado separa naturalmente: Solana adopta un mecanismo de declaración de bloqueo de cuentas, MoveVM introduce un modelo de propiedad de objetos, y Sei v2 clasifica según los tipos de transacciones para lograr una determinación de conflictos estática, apoyando la programación concurrente a nivel de transacciones.
• Optimización de la concurrencia de la máquina virtual: el motor Sealevel de Solana admite de forma nativa la ejecución multihilo; MoveVM puede realizar análisis de gráficos de concurrencia estáticos; Sei v2 integra un motor de emparejamiento multihilo y un módulo VM paralelo.

Por supuesto, este tipo de cadena paralela nativa también enfrenta desafíos de compatibilidad ecológica. Las arquitecturas no EVM a menudo requieren lenguajes de desarrollo totalmente nuevos (como Move, Rust) y cadenas de herramientas, lo que presenta un cierto costo de migración para los desarrolladores; además, los desarrolladores también deben dominar una serie de nuevos conceptos como modelos de acceso al estado, límites de concurrencia y ciclos de vida de objetos, todos los cuales elevan el umbral de comprensión e imponen mayores demandas sobre los paradigmas de desarrollo.

3.1 El principio de Solana y el motor paralelo Sealevel de SVM

El modelo de ejecución Sealevel de Solana es un mecanismo de programación paralela basado en cuentas, que es el motor central utilizado por Solana para lograr la ejecución de transacciones paralelas en la cadena. A través del mecanismo de "declaración de cuenta + programación estática + ejecución multihilo", se realiza una alta concurrencia de rendimiento a nivel de contratos inteligentes. Sealevel es el primer modelo de ejecución en el campo de la blockchain que implementa con éxito la programación concurrente en la cadena en un entorno de producción, y sus ideas arquitectónicas han influido en muchos proyectos posteriores de computación paralela, sirviendo como un paradigma de referencia para el diseño paralelo de alto rendimiento en la Capa 1.

Mecanismo Central:

1. Declaración Explícita de Acceso a la Cuenta (Listas de Acceso a Cuentas): Cada transacción debe declarar las cuentas involucradas (lectura/escritura) en el momento de la presentación, permitiendo al sistema determinar si hay conflictos de estado entre transacciones.

2. Detección de Conflictos y Programación Multihilo

• Si el conjunto de cuentas accedido por las dos transacciones no tiene intersección → pueden ejecutarse en paralelo;
• Existe un conflicto → Ejecutar en serie en orden de dependencia;
• El programador asigna transacciones a diferentes hilos en función del gráfico de dependencias.

3. Contexto de Ejecución Independiente (Contexto de Invocación del Programa): Cada llamada a un contrato opera en un contexto aislado, sin pila compartida, lo que previene la interferencia entre llamadas.

Sealevel es el motor de programación de ejecución paralela de Solana, mientras que SVM es el entorno de ejecución de contratos inteligentes construido sobre Sealevel (utilizando la máquina virtual BPF). Juntos, forman la base técnica del sistema de ejecución paralela de alto rendimiento de Solana.

Eclipse es un proyecto que implementa la VM de Solana en cadenas modulares (como Ethereum L2 o Celestia), utilizando el motor de ejecución paralela de Solana como la capa de ejecución de Rollup. Eclipse es uno de los primeros proyectos en proponer desacoplar la capa de ejecución de Solana (Sealevel + SVM) de la mainnet de Solana y migrarla a una arquitectura modular, modularizando el "modelo de ejecución concurrente súper fuerte" de Solana como Capa de Ejecución como Servicio. Por lo tanto, Eclipse también se clasifica dentro de la computación paralela.

El enfoque de Neon es diferente; introduce la EVM para ejecutarse en el entorno SVM / Sealevel. Construye una capa de ejecución compatible con la EVM, lo que permite a los desarrolladores utilizar Solidity para desarrollar contratos que se ejecutan en el entorno SVM, pero la ejecución programada utiliza SVM + Sealevel. Neon está más inclinado hacia la categoría de Blockchain Modular en lugar de enfatizar innovaciones en la computación paralela.

En resumen, Solana y SVM se basan en el motor de ejecución Sealevel, y la filosofía de programación del sistema operativo Solana es similar a la de un programador de núcleo, ejecutando rápidamente pero con una flexibilidad relativamente baja. Es una cadena pública nativa de alto rendimiento y computación paralela.

3.2 Arquitectura MoveVM: Impulsada por Recursos y Objetos

MoveVM es una máquina virtual de contratos inteligentes diseñada para la seguridad de los recursos en cadena y la ejecución paralela. Su lenguaje central, Move, fue desarrollado originalmente por Meta (anteriormente Facebook) para el proyecto Libra, enfatizando el concepto de “recurso como un objeto”. Todos los estados en cadena existen como objetos con propiedad y ciclo de vida claros. Esto permite que MoveVM analice si hay conflictos de estado entre transacciones en tiempo de compilación, habilitando la programación paralela estática a nivel de objeto, y se utiliza ampliamente en cadenas públicas nativas paralelas como Sui y Aptos.

El modelo de propiedad de objetos de Sui
La capacidad de computación paralela de Sui proviene de su enfoque único de modelado del estado y su mecanismo de análisis estático a nivel de lenguaje. A diferencia de las blockchains tradicionales que utilizan un árbol de estado global, Sui ha construido un conjunto de modelos de estado centrados en objetos, combinados con el sistema de tipos lineales de MoveVM, lo que permite que la programación paralela sea un proceso determinista que se puede completar en tiempo de compilación.

• El Modelo de Objetos es la base de la arquitectura paralela de Sui. Sui abstrae todos los estados en la cadena en objetos independientes, cada uno con un ID único, un propietario claro (cuenta o contrato) y definiciones de tipo. Estos objetos no comparten estados entre sí, proporcionando un aislamiento natural. Los contratos deben declarar explícitamente el conjunto de objetos involucrados al ser invocados, evitando los problemas de acoplamiento de estado del tradicional "árbol de estado global" en la cadena. Este diseño descompone los estados en la cadena en varias unidades independientes, haciendo que la ejecución concurrente sea una premisa de programación estructuralmente factible.
• El Análisis de Propiedad Estática es un mecanismo de análisis en tiempo de compilación implementado bajo el apoyo del sistema de tipos lineales del lenguaje Move. Permite al sistema inferir qué transacciones no causarán conflictos de estado a través de la propiedad de los objetos antes de que se ejecuten las transacciones, organizándolas así para su ejecución en paralelo. En comparación con la detección de conflictos en tiempo de ejecución tradicional y la reversión, el mecanismo de análisis estático de Sui mejora significativamente la eficiencia de ejecución mientras reduce en gran medida la complejidad de programación, lo que es clave para lograr un alto rendimiento y capacidades de procesamiento paralelo determinista.

Sui divide el espacio de estado en función de los objetos y combina el análisis de propiedad en tiempo de compilación para lograr una ejecución paralela a nivel de objeto de bajo costo y sin retrocesos. En comparación con la ejecución en serie o las comprobaciones en tiempo de ejecución de las cadenas tradicionales, Sui ha logrado mejoras significativas en la eficiencia de ejecución, la determinación del sistema y la utilización de recursos.

El mecanismo de ejecución Block-STM de Aptos
Aptos es una blockchain de alto rendimiento de Capa 1 basada en el lenguaje Move, cuya capacidad de ejecución paralela proviene principalmente del marco autodesarrollado Block-STM (Memoria Transaccional a Nivel de Bloque). A diferencia de Sui, que tiende a adoptar una estrategia de "paralelismo estático en tiempo de compilación", Block-STM pertenece a un mecanismo de programación dinámica de "concurrencia optimista en tiempo de ejecución + retroceso de conflictos", adecuado para manejar conjuntos de transacciones con dependencias complejas.

Block-STM divide la ejecución de las transacciones de un bloque en tres fases:

• Ejecución especulativa: Se supone que todas las transacciones son libres de conflictos antes de la ejecución, y el sistema programa transacciones en múltiples hilos para su ejecución concurrente, registrando los estados de cuenta a los que acceden (conjunto de lectura / conjunto de escritura).
• Fase de Detección y Validación de Conflictos: El sistema verifica los resultados de la ejecución: si dos transacciones tienen un conflicto de lectura-escritura (por ejemplo, Tx1 lee el estado escrito por Tx2), una de ellas será revertida.
• Reintento de reversión de transacciones en conflicto (Fase de reintento): Las transacciones en conflicto se reprogramarán para su ejecución hasta que se resuelvan sus dependencias, formando en última instancia una secuencia de compromiso de estado válida y determinista para todas las transacciones.

Block-STM es un modelo de ejecución dinámica que emplea "paralelismo optimista + reintento de retroceso", adecuado para escenarios de procesamiento por lotes de transacciones en cadena que son intensivos en estado y lógicamente complejos. Es el núcleo de la computación paralela para que Aptos construya una cadena pública altamente versátil y de alto rendimiento.

Solana es la facción de programación de ingeniería, más como un "núcleo de sistema operativo". Es adecuada para límites de estado claros y comercio de alta frecuencia controlable, personificando un estilo de ingeniero de hardware, y está diseñada para ejecutar la cadena como hardware (ejecución paralela de grado hardware). Aptos es la facción de tolerancia a fallos del sistema, más como un "motor de concurrencia de base de datos". Es adecuada para contratos con un fuerte acoplamiento de estado y cadenas de llamadas complejas. Sui es la facción de seguridad en tiempo de compilación, más como una "plataforma de lenguaje inteligente orientada a recursos". Es adecuada para aplicaciones en cadena con separación de activos y combinaciones claras. Aptos y Sui están destinadas a operar la cadena como ingenieros de lenguajes de programación, asegurando la seguridad de recursos de grado software. Los tres representan diferentes caminos filosóficos para la implementación técnica de la computación paralela en Web3.

3.3 Tipo de escalado paralelo de Cosmos SDK

Sei V2 es una cadena pública de trading de alto rendimiento construida sobre el Cosmos SDK. Sus capacidades paralelas se reflejan principalmente en dos aspectos: el motor de emparejamiento multi-hilo y la optimización de ejecución paralela en la capa de máquina virtual, con el objetivo de servir a escenarios de trading en cadena de alta frecuencia y baja latencia, como DEXs de libro de órdenes e infraestructura de intercambio en cadena.

Mecanismo Paralelo Central:

• Motor de Emparejamiento Paralelo: Sei V2 introduce un camino de ejecución de múltiples hilos en la lógica de emparejamiento de órdenes, separando el libro de órdenes de la lógica de emparejamiento a nivel de hilo, permitiendo que las tareas de emparejamiento entre múltiples mercados (pares de negociación) se procesen en paralelo, evitando así los cuellos de botella de un solo hilo.
• Optimización de Concurrencia a Nivel de Máquina Virtual: Sei V2 ha construido un entorno de ejecución CosmWasm con capacidades de ejecución concurrente, permitiendo que ciertas llamadas a contratos se ejecuten en paralelo bajo la condición de que sus estados no entren en conflicto, y logrando un mayor control de rendimiento en conjunto con un mecanismo de clasificación de tipos de transacción.
• Consenso paralelo combinado con programación de la capa de ejecución: Introduciendo el llamado mecanismo de consenso "Twin-Turbo" para fortalecer el desacoplamiento del rendimiento entre la capa de consenso y la capa de ejecución, mejorando la eficiencia general del procesamiento de bloques.

3.4 Reconstructor de Modelo UTXO Combustible

Fuel es una capa de ejecución de alto rendimiento diseñada sobre la arquitectura modular de Ethereum, con su mecanismo paralelo central derivado de un modelo UTXO mejorado (Unspent Transaction Output). A diferencia del modelo de cuentas de Ethereum, Fuel utiliza una estructura UTXO para representar activos y estados, que posee inherentemente aislamiento de estado, lo que facilita determinar qué transacciones se pueden ejecutar de manera segura en paralelo. Además, Fuel introduce un lenguaje de contratos inteligentes autodesarrollado llamado Sway (similar a Rust), y lo combina con herramientas de análisis estático para identificar conflictos de entrada antes de la ejecución de transacciones, logrando así una programación paralela eficiente y segura a nivel de transacciones. Sirve como una capa de ejecución alternativa EVM que equilibra el rendimiento y la modularidad.

4. Modelo de Actor: Un Nuevo Paradigma para la Ejecución Concurrente de Agentes

El Modelo Actor es un paradigma de ejecución paralela que utiliza procesos de agente (Agente o Proceso) como unidades, diferenciándose de la computación síncrona tradicional con un estado global en la cadena (escenarios como "computación paralela en la cadena" como Solana/Sui/Monad), ya que enfatiza que cada agente tiene su propio estado y comportamiento independiente, comunicándose y programando a través de mensajes asíncronos. Bajo esta arquitectura, los sistemas en la cadena pueden ejecutar simultáneamente un gran número de procesos desacoplados, proporcionando una fuerte escalabilidad y tolerancia a fallos asíncrona. Proyectos representativos incluyen AO (Arweave AO), ICP (Internet Computer) y Cartesi, que están impulsando la evolución de la blockchain de un motor de ejecución a un "sistema operativo en la cadena", proporcionando infraestructura nativa para Agentes de IA, interacciones multitarea y orquestación de lógica compleja.

Aunque el diseño del Modelo de Actor tiene ciertas similitudes superficiales con el Sharding (como la concurrencia, el aislamiento del estado y el procesamiento asíncrono), en esencia representan caminos técnicos y filosofías de sistema completamente diferentes. El Modelo de Actor enfatiza la "computación asíncrona multiproceso", donde cada agente (Actor) opera de manera independiente y mantiene su propio estado, interactuando a través de un enfoque impulsado por mensajes; mientras que el Sharding es un mecanismo para la "partición horizontal del estado y consenso", dividiendo toda la blockchain en múltiples subsistemas independientes (Shards) que procesan transacciones. El Modelo de Actor es más como un "sistema operativo de agentes distribuidos" en el mundo Web3, mientras que el Sharding es una solución de escalado estructural para las capacidades de procesamiento de transacciones en la cadena. Ambos logran concurrencia, pero sus puntos de partida, objetivos y arquitecturas de ejecución son diferentes.

4.1 AO (Arweave), una supercomputadora paralela por encima de la capa de almacenamiento

AO es una plataforma de computación descentralizada que opera en la capa de almacenamiento permanente de Arweave, con el objetivo principal de construir un sistema operativo en cadena que soporte la operación de agentes asincrónicos a gran escala.

Características de la Arquitectura Central:

• Arquitectura de procesos: Cada agente se denomina Proceso, poseyendo un estado independiente, un programador independiente y lógica de ejecución.
• No hay estructura de blockchain: AO no es una cadena, sino una capa de almacenamiento descentralizada basada en Arweave + un motor de ejecución impulsado por mensajes multiagente;
• Sistema de Programación de Mensajes Asincrónicos: Los procesos se comunican a través de mensajes, adoptando un modelo operativo asincrónico sin bloqueos, que admite de manera inherente la escalabilidad concurrente;
• Almacenamiento permanente de estado: Todos los estados de los agentes, registros de mensajes e instrucciones se registran permanentemente en Arweave, asegurando una auditoría completa y transparencia descentralizada.
• Agente nativo: Adecuado para desplegar tareas complejas de múltiples pasos (como agentes de IA, controladores del protocolo DePIN, orquestadores de tareas automatizadas, etc.), puede construir un "Coprocesador de IA en cadena."

AO sigue un enfoque extremo de "cuerpo inteligente nativo + impulsado por almacenamiento + arquitectura sin cadena", enfatizando la flexibilidad y el desacoplamiento modular. Es un "marco de microkernel construido sobre la capa de almacenamiento", con límites de sistema intencionadamente reducidos, enfatizando la computación ligera + estructuras de control componibles.

4.2 ICP (Internet Computer), una plataforma de alojamiento Web3 de pila completa

ICP es una plataforma de aplicaciones en cadena de pila completa nativa de Web3 lanzada por DFINITY, que tiene como objetivo extender las capacidades de computación en cadena a una experiencia similar a Web2, y admite alojamiento completo de servicios, vinculación de dominios y una arquitectura sin servidor.

Características de la arquitectura central:

• Arquitectura de canisters (contenedores como agentes inteligentes): Cada canister es un agente inteligente que se ejecuta en la máquina virtual Wasm, poseyendo un estado independiente, código y capacidades de programación asíncrona;
• Sistema de Consenso Distribuido por Subredes: Toda la red está compuesta por múltiples Subredes, cada una de las cuales mantiene un grupo de Canisters y alcanza consenso a través del mecanismo de firma BLS.
• Modelo de llamada asíncrona: Los canisters se comunican entre sí a través de mensajes asíncronos, lo que soporta la ejecución no bloqueante y tiene un paralelismo inherente;
• Alojamiento Web en la cadena: Soporta contratos inteligentes para alojar directamente páginas front-end, con mapeo DNS nativo, convirtiéndose en la primera plataforma blockchain que soporta acceso directo a dApps desde el navegador.
• Funciones del sistema integrales: Equipado con actualizaciones en caliente en la cadena, autenticación de identidad, aleatoriedad distribuida, temporizadores y otras API del sistema, adecuado para el despliegue de servicios complejos en la cadena.

ICP selecciona una plataforma pesada, encapsulación integrada y un paradigma de sistema operativo de control de plataforma fuerte, con un "Sistema Operativo Blockchain" que integra consenso, ejecución, almacenamiento y acceso. Enfatiza capacidades completas de alojamiento de servicios, y el límite del sistema se expande a una plataforma de alojamiento Web3 de pila completa.

Además, otros proyectos de computación paralela basados en el paradigma del Modelo de Actor pueden referirse a la tabla a continuación:

V. Resumen y Perspectivas

Basado en las diferencias en la arquitectura de máquinas virtuales y sistemas de lenguaje, las soluciones de computación paralela en blockchain se pueden dividir en dos categorías: cadenas de mejora paralela basadas en EVM y cadenas de arquitectura paralela nativa (no EVM).

El primero logra un mayor rendimiento y capacidades de procesamiento paralelo a través de una profunda optimización de la capa de ejecución, manteniendo la compatibilidad con el ecosistema EVM/Solidity. Es adecuado para escenarios donde hay un deseo de heredar activos y herramientas de desarrollo de Ethereum, al mismo tiempo que se logran avances en el rendimiento. Los proyectos representativos incluyen:

• Monad: Logra un modelo de ejecución paralela optimista compatible con EVM a través de escrituras retrasadas y detección de conflictos en tiempo de ejecución, construyendo un grafo de dependencias y programando la ejecución con multithreading después de que se alcanza el consenso.
• MegaETH: Abstracta cada cuenta/contrato como un Micro-VM independiente, logrando una programación paralela a nivel de cuenta altamente desacoplada basada en mensajería asíncrona y gráficos de dependencia de estado.
• Pharos: Construyendo una arquitectura de Rollup Mesh que colabora con el módulo SPN a través de tuberías asíncronas para lograr un procesamiento paralelo a nivel de sistema entre procesos.
• Reddio: Adopta una arquitectura zkRollup + GPU, centrada en acelerar el proceso de verificación fuera de la cadena de zkEVM a través de la generación masiva de SNARK, mejorando el rendimiento de la verificación.

El último se libera completamente de las limitaciones de compatibilidad con Ethereum, rediseñando el paradigma de ejecución desde la máquina virtual, el modelo de estado y el mecanismo de programación para lograr capacidades de concurrencia nativas de alto rendimiento. Las subclases típicas incluyen:

• Solana (Sistema SVM): Basado en declaraciones de acceso a cuentas y programación de gráficos de conflicto estáticos, representando un modelo de ejecución paralelo a nivel de cuenta;
• Sui / Aptos (Sistema MoveVM): Basado en el modelo de objeto de recurso y el sistema de tipos, admite análisis estático en tiempo de compilación y logra paralelismo a nivel de objeto.
• Sei V2 (Ruta del SDK de Cosmos): Introduce un motor de coincidencia multihilo y optimización de concurrencia de máquina virtual dentro de la arquitectura de Cosmos, adecuado para aplicaciones de comercio de alta frecuencia.
• Fuel (UTXO + arquitectura Sway): Logrando paralelismo a nivel de transacción a través del análisis estático de conjuntos de entradas UTXO, combinado con una capa de ejecución modular y el lenguaje de contrato inteligente personalizado Sway.

Además, el Modelo de Actor, como un sistema paralelo más amplio, construye un paradigma de ejecución en cadena de "operación independiente de múltiples agentes + colaboración impulsada por mensajes" a través de un mecanismo de programación de procesos asíncronos basado en Wasm o VMs personalizadas. Proyectos representativos incluyen:

• AO (Arweave AO): Un runtime de agente impulsado por almacenamiento permanente, construyendo un sistema de microkernel asíncrono en la cadena.
• ICP (Computadora Internet): Logra una ejecución de alta escalabilidad asíncrona a través de la coordinación de subredes con el agente en contenedor (Canister) como la unidad más pequeña.
• Cartesi: Introduce el sistema operativo Linux como un entorno de computación fuera de la cadena, proporcionando un camino de verificación en la cadena para resultados de computación confiables, adecuado para escenarios de aplicación complejos o que requieren muchos recursos.

Basado en la lógica anterior, podemos categorizar las soluciones de cadenas públicas de computación paralela que son actualmente mainstream en la estructura de clasificación que se muestra en el gráfico a continuación:

Desde una perspectiva más amplia de escalado, el sharding y los rollups (L2) se centran en lograr el escalado horizontal del sistema a través de la partición del estado o la ejecución fuera de la cadena, mientras que las cadenas de computación paralela (como Monad, Sui, Solana) y los sistemas orientados a actores (como AO, ICP) reconstruyen directamente el modelo de ejecución para lograr un paralelismo nativo a nivel de cadena o sistema. Los primeros mejoran el rendimiento en cadena mediante métodos como máquinas virtuales multihilo, modelos de objetos y análisis de conflictos de transacciones; los últimos utilizan procesos/agentes como unidades básicas y adoptan métodos de ejecución impulsados por mensajes y asíncronos para permitir la operación concurrente de múltiples agentes. En comparación, el sharding y los rollups son más como 'distribuir la carga a través de múltiples cadenas' o 'subcontratar a la cadena fuera', mientras que las cadenas paralelas y el modelo de actores se centran en 'liberar el potencial de rendimiento del propio motor de ejecución', reflejando una dirección de evolución arquitectónica más profunda.

Comparación de Computación Paralela vs Arquitectura de Shard vs Escalabilidad de Rollup vs Ruta de Extensión Orientada a Actores

Cabe destacar que la mayoría de las cadenas de arquitectura paralela nativa han entrado ahora en la etapa de lanzamiento de mainnet. Aunque el ecosistema general de desarrolladores todavía es difícil de comparar con el sistema Solidity basado en EVM, proyectos representados por Solana y Sui, con su arquitectura de ejecución de alto rendimiento y la creciente prosperidad de las aplicaciones ecológicas, se han convertido en las cadenas públicas centrales que atraen la atención significativa del mercado.

En contraste, aunque el ecosistema de Rollup de Ethereum (L2) ha entrado en la etapa de "muchas cadenas apresurándose a lanzar" o incluso "sobrecapacidad", las cadenas de mejora paralela compatibles con EVM que son actualmente principales todavía están en su mayoría en la etapa de testnet y no han sido verificadas en un entorno de mainnet. Sus capacidades de escalado y la estabilidad del sistema aún requieren un examen adicional. En cuanto a si estos proyectos pueden mejorar significativamente el rendimiento de EVM y promover la evolución ecológica sin sacrificar la compatibilidad, o si, en cambio, exacerbarán la diferenciación adicional de la liquidez y los recursos de desarrollo en Ethereum, está por verse.

Declaración:

1. Este artículo se reproduce de [TechFlow] Los derechos de autor pertenecen al autor original [0xjacobzhao y ChatGPT 4o] Si tiene alguna objeción a la reimpresión, por favor contáctenos Equipo de Gate LearnEl equipo lo procesará lo más rápido posible de acuerdo con los procedimientos relevantes.
2. Descargo de responsabilidad: Las opiniones y puntos de vista expresados en este artículo son únicamente del autor y no constituyen ningún consejo de inversión.
3. Otras versiones del artículo en otros idiomas son traducidas por el equipo de Gate Learn, a menos que se mencione lo contrario.PuertaBajo ninguna circunstancia se podrán copiar, difundir o plagiar artículos traducidos.