Web3 Parallel Computing Track Panorama: ¿La mejor solución para el escalado nativo?

Autor: 0xjacobzhao y ChatGPT 4oEl

"trilema de la cadena de bloques" de "seguridad", "descentralización" y "escalabilidad" de la cadena de bloques revela la compensación esencial en el diseño de los sistemas de cadena de bloques, es decir, es difícil que los proyectos de cadena de bloques logren "seguridad extrema, todos pueden participar y procesamiento de alta velocidad" al mismo tiempo. En respuesta al eterno tema de la "escalabilidad", las principales soluciones de escalado de blockchain en el mercado se dividen según paradigmas, que incluyen:

• Escalado mejorado por la ejecución: mejora las capacidades de ejecución in situ, como el paralelismo, la GPU y
el escalado aislado del estado de varios núcleos
• : Dividido horizontalmente del estado/fragmento, por ejemplo, fragmentos, UTXO y múltiples subredes
• Escalado subcontratado fuera de la cadena: Poner la ejecución fuera de la cadena, como rollups, Escalado
de desacoplamiento de estructura de coprocesador y DA
• : arquitectura modular y operación colaborativa, como cadena de módulos, secuenciador compartido, Rollup Mesh
• Escalado simultáneo asíncrono: modelo de actor, aislamiento de procesos, controlado por mensajes, como agente, cadena asíncrona multihilo

  La solución de escalado de blockchain incluye: computación paralela en cadena, rollup, fragmentación, módulo DA, estructura modular, sistema de actores, compresión a prueba de zk, arquitectura sin estado, etc., que cubre múltiples niveles de ejecución, estado, datos y estructura, y es un sistema de escalado completo de "colaboración multicapa y combinación de módulos". Este artículo se centra en los métodos de escalado que generalizan la computación paralela.

  Paralelismo dentro de la cadena, que 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 de las cuales representa una búsqueda de rendimiento, un modelo de desarrollo y una filosofía de arquitectura diferentes, y la granularidad paralela es cada vez más fina, la intensidad del paralelismo es cada vez mayor, la complejidad de la programación es cada vez mayor, y la complejidad de la programación y la dificultad de implementación también son cada vez más altas.

  • Nivel de cuenta: Representa el proyecto
  • Nivel de objeto: Representa el proyecto Sui
  • Nivel de transacción: Representa el proyecto Monad, Aptos
  • Call-level / MicroVM : Nivel de instrucción MegaETH:
  • GatlingX

  El modelo de concurrencia asíncrona fuera de la cadena, representado por el Modelo Actor / Actor, pertenece a otro paradigma de computación paralela, como un sistema de mensajes entre cadenas / asincrónico (modelo de sincronización sin bloques), cada agente se ejecuta de forma independiente como un "proceso de agente", mensajes asíncronos en modo paralelo, impulsados por eventos, sin programación sincrónica, proyectos representativos como AO, ICP, Cartesi, etc.

  El conocido esquema de escalado de fragmentos o rollup pertenece al mecanismo de simultaneidad a nivel del sistema, no a la computación paralela dentro de la cadena. Logran el escalado "ejecutando múltiples cadenas/dominios de ejecución en paralelo", en lugar de aumentar el paralelismo dentro de un solo bloque/máquina virtual. Este tipo de solución de escalado no es el foco de este artículo, pero aún así lo usaremos para comparar las similitudes y diferencias en los conceptos arquitectónicos.

  

  2. Cadena de mejora paralela de EVM: rompiendo el límite de rendimiento en

  compatibilidad Desde el desarrollo de la arquitectura de procesamiento en serie de Ethereum, se ha sometido a múltiples rondas de intentos de escalado, como la fragmentación, la acumulación y la arquitectura modular, pero el cuello de botella de rendimiento de la capa de ejecución aún no se ha roto fundamentalmente. Pero al mismo tiempo, EVM y Solidity siguen siendo las plataformas de contratos inteligentes con la mayor base de desarrolladores y potencial ecológico. Por lo tanto, la cadena de mejora paralela de EVM se está convirtiendo en una dirección importante para una nueva ronda de escalado y evolución como un camino clave que tiene en cuenta 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, partiendo de la ejecución diferida y la descomposición de estados respectivamente, para construir una arquitectura de procesamiento paralelo de EVM para escenarios de alta concurrencia y alto rendimiento.

  Análisis de computación paralela de MonadMonad

  es una cadena de bloques de capa 1 de alto rendimiento rediseñada para la máquina virtual Ethereum (EVM), basada en el concepto paralelo básico de canalización, con ejecución asíncrona en la capa de consenso y concurrencia optimista en la capa de ejecución Ejecución paralela) 。 Además, en las capas de consenso y almacenamiento, Monad ha introducido el protocolo BFT de alto rendimiento (MonadBFT) y un sistema de base de datos dedicado (MonadDB) respectivamente para lograr la optimización de extremo a extremo.

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

  La canalización es el concepto básico de la ejecución paralela de Monad, y su idea central es dividir el proceso de ejecución de la cadena de bloques en múltiples etapas independientes y procesar estas etapas en paralelo para formar una arquitectura de tubería tridimensional, cada etapa se ejecuta en subprocesos o núcleos independientes para lograr un procesamiento simultáneo entre bloques. El resultado es un mayor rendimiento y una reducción de la latencia. Estas etapas incluyen: Proponer, Consenso, Ejecutar y Confirmar.

  Ejecución asíncrona: consenso: la ejecución se desacopla de forma asíncronaEn

  las cadenas tradicionales, el consenso y la ejecución de transacciones suelen ser procesos sincrónicos, y este modelo en serie limita gravemente el escalado del rendimiento. Monad implementa la capa de consenso asíncrona, la capa de ejecución asíncrona y el almacenamiento asíncrono a través de la "ejecución asíncrona". Reduzca significativamente el tiempo de bloqueo y la latencia de confirmación, haciendo que el sistema sea más resistente, el procesamiento más segmentado y la utilización de recursos.

  Diseño central:

  El
  • proceso de consenso (capa de consenso) solo es responsable de clasificar las transacciones y no ejecuta la lógica del contrato.
  • El proceso de ejecución (capa de ejecución) se desencadena de forma asíncrona una vez completado el consenso.
  • Una vez completado el consenso, entrará en el proceso de consenso del siguiente bloque inmediatamente, sin esperar a que se complete la ejecución.

  Ejecución paralela optimista: Ejecución paralela optimistaEthereum tradicional

  adopta un modelo estrictamente en serie para la ejecución de transacciones para evitar conflictos de estado. Monad, por otro lado, adopta una estrategia de "ejecución paralela optimista" para aumentar significativamente la velocidad de procesamiento de las transacciones.

  Mecanismo de ejecución:

  • Monad ejecuta de manera optimista todas las transacciones en paralelo, asumiendo que la mayoría de las transacciones son sin estado y libres de conflictos.
  • Ejecute también un "Detector de conflictos" para supervisar si se accede al mismo estado (por ejemplo, conflictos de lectura/escritura) entre transacciones.
  • Si se detecta un conflicto, la transacción en conflicto se serializa y se vuelve a ejecutar para asegurarse de que el estado es correcto.

  Monad ha elegido un camino compatible: mover la menor cantidad posible de reglas de EVM, lograr un paralelismo difiriendo el estado de escritura y detectando dinámicamente conflictos durante la ejecución, que se parece más a una versión de rendimiento de Ethereum, con un nivel de madurez que facilita la migración al ecosistema de EVM, y es un acelerador paralelo en el mundo de EVM.

  La resolución del mecanismo de computación paralela de MegaETH

  es diferente del posicionamiento L1 de Monad, y MegaETH se posiciona como una capa de ejecución paralela modular de alto rendimiento compatible con EVM, que se puede utilizar como una cadena pública L1 independiente, como una capa de mejora de la ejecución o un componente modular en Ethereum. Su objetivo principal de diseño es deconstruir la lógica de la cuenta, el entorno de ejecución y el aislamiento de estado en la unidad más pequeña que se pueda programar de forma independiente para lograr una ejecución de alta simultaneidad y una capacidad de respuesta de baja latencia dentro de la cadena. La innovación clave propuesta por MegaETH es que la arquitectura Micro-VM + State Dependency DAG (gráfico de dependencias de estado dirigido y acíclico) y el mecanismo de sincronización modular construyen conjuntamente un sistema de ejecución paralelo para el "subprocesamiento dentro de la cadena".

  Arquitectura de micro-VM: las cuentas son hilos

  MegaETH introduce el modelo de ejecución de "una micro-VM por cuenta", que "sublate" el entorno de ejecución y proporciona una unidad de aislamiento mínima para la programación paralela. Estas máquinas virtuales se comunican entre sí a través de mensajería asincrónica en lugar de llamadas sincrónicas, y un gran número de máquinas virtuales se pueden ejecutar de forma independiente, almacenar de forma independiente y, de forma natural, en paralelo.

  DAG de dependencia de estado: un mecanismo de programación basado en gráficos

  MegaETH ha creado un sistema de programación DAG basado en la relación de acceso al estado de la cuenta, y el sistema mantiene un gráfico de dependencias global en tiempo real, y las cuentas que se modifican y las cuentas que se leen para cada transacción se modelan en dependencias. Las transacciones libres de conflictos se pueden ejecutar directamente en paralelo, y las transacciones dependientes se programarán y ordenarán en serie o se aplazarán en orden topológico. Los gráficos de dependencias garantizan la coherencia de estado y las escrituras no duplicadas durante la ejecución en paralelo.

  El

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

  MegaETH se basa en el paradigma de programación asíncrona, similar al paso de mensajes asíncronos del modelo de actor, para resolver el problema de las llamadas seriales EVM tradicionales. Las llamadas de contrato son asincrónicas (ejecución no recursiva) y cuando se llama al contrato A -> B -> C, cada llamada es asincrónica sin bloquear la espera; La pila de llamadas se expande en un gráfico de llamadas asincrónicas; Procesamiento de transacciones = recorrido de grafo asíncrono + resolución de dependencias + programación paralela.

  Con todo, MegaETH rompe el modelo tradicional de máquina de estado de un solo subproceso de EVM, implementa la encapsulación de micromáquinas virtuales cuenta por cuenta, realiza la programación de transacciones a través de gráficos dependientes del estado y reemplaza la pila de llamadas sincrónicas con un mecanismo de mensajería asíncrona. Es una plataforma de computación paralela que se rediseña a partir de las dimensiones completas de la "estructura de la cuenta→ la arquitectura de programación → el proceso de ejecución", proporcionando una nueva idea a nivel de paradigma para construir un sistema en cadena de alto rendimiento de próxima generación.

  MegaETH ha elegido el camino de la refactorización: abstrae completamente las cuentas y los contratos en máquinas virtuales independientes, y libera el máximo potencial de paralelismo a través de la programación de ejecución asíncrona. Teóricamente, MegaETH tiene un límite paralelo más alto, pero también es más difícil de controlar la complejidad, y se parece más a un sistema operativo superdistribuido bajo el concepto de Ethereum.

  

  Monad y MegaETH Ambos tienen conceptos de diseño diferentes a los de la fragmentación: la fragmentación divide horizontalmente la cadena de bloques en múltiples subcadenas independientes (fragmentos), cada una de las cuales es responsable de parte de las transacciones y el estado, rompiendo la limitación de una sola cadena y escalando en la capa de red; Por otro lado, tanto Monad como MegaETH mantienen la integridad de la cadena única, escalando horizontalmente solo en la capa de ejecución y realizando avances de optimización en paralelo en el límite de la cadena única. Los dos representan dos direcciones: el fortalecimiento vertical y la expansión horizontal en el camino de expansión de la cadena de bloques.

  Los proyectos de computación paralela como Monad y MegaETH se centran principalmente en la ruta de optimización del rendimiento, con el objetivo principal de mejorar el TPS en la cadena y lograr el procesamiento paralelo a nivel de transacción o de cuenta a través de la ejecución diferida y las arquitecturas de micro-VM. Pharos Network es una red de cadena de bloques L1 paralela modular y de pila completa, y su sistema central de computación paralela se llama "Rollup Mesh". Esta arquitectura admite entornos de múltiples máquinas virtuales (EVM y Wasm) a través de la sinergia de la red principal y las redes de procesamiento especiales (SPN), e integra tecnologías avanzadas como pruebas de conocimiento cero (ZK) y entornos de ejecución de confianza (TEE).

  Análisis de computación paralela de Rollup Mesh:

  1. Canalización asíncrona de ciclo de vida completo: Pharos desacopla las diversas etapas de una transacción (como el consenso, la ejecución y el almacenamiento) y adopta el procesamiento asíncrono para que cada etapa se pueda llevar a cabo de forma independiente y en paralelo, mejorando así la eficiencia general del procesamiento.
  2. Ejecución paralela de doble máquina virtual: Pharos es compatible con los entornos de máquinas virtuales EVM y WASM, lo que permite a los desarrolladores elegir el entorno de ejecución adecuado para sus necesidades. Esta arquitectura de doble máquina virtual no solo aumenta la flexibilidad del sistema, sino que también aumenta el procesamiento de transacciones a través de la ejecución en paralelo.
  3. Redes especiales de procesamiento (SPN): Las SPN son componentes clave en la arquitectura Pharos, similares a las subredes modulares diseñadas para manejar tipos específicos de tareas o aplicaciones. Con los SPN, Pharos permite 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 replanteo: Pharos presenta un mecanismo de consenso flexible que admite múltiples modelos de consenso (como PBFT, PoS, PoA) y permite el intercambio seguro y la integración de recursos entre la red principal y los SPN a través del protocolo de replanteo.

  Además, Pharos reconstruye el modelo de ejecución desde la capa inferior del motor de almacenamiento a través de la tecnología de árbol Merkle de múltiples versiones, codificación Delta, direccionamiento versionado y ADS Pushdown, y lanza Pharos Store, un motor de almacenamiento de alto rendimiento para la cadena de bloques nativa, para lograr un alto rendimiento, baja latencia y sólidas capacidades de procesamiento en cadena verificables.

  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.

  Además de las arquitecturas de ejecución paralela de Monad, MegaETH y Pharos, también observamos que hay algunos proyectos en el mercado que exploran la ruta de aplicación de la aceleración de GPU en la computación paralela de EVM, 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 la arquitectura de ejecución paralela de GPU, y su núcleo radica en la reconstrucción del proceso de ejecución de EVM y la realización de la paralelización nativa de la capa de ejecución a través de la programación multihilo, el almacenamiento de estado asíncrono y la ejecución acelerada por GPU de lotes de transacciones. Granularidad paralela a nivel de transacción + nivel de operación (código de operación de ejecución multiproceso). Está diseñado para introducir la ejecución por lotes multiproceso, la carga de estado asincrónica y la lógica de transacción de procesamiento paralelo de GPU (EVM paralela compatible con CUDA). Al igual que Monad / MegaETH, Reddio también se centra en el procesamiento paralelo en la capa de ejecución, con la diferencia de que el motor de ejecución se reconstruye a través de una arquitectura paralela a la GPU, diseñada para escenarios de alto rendimiento y computación intensiva, como la inferencia de IA. GatlingX,
  • que se autodenomina "GPU-EVM", propone una arquitectura más radical que intenta migrar el modelo de "ejecución en serie a nivel de instrucción" de las máquinas virtuales EVM tradicionales a un entorno de tiempo de ejecución paralelo nativo de GPU. El mecanismo central es compilar dinámicamente el código de bytes de EVM en tareas paralelas CUDA y ejecutar el flujo de instrucciones a través del núcleo múltiple de la GPU, para romper el cuello de botella secuencial de la EVM en el nivel más bajo. Granularidad paralela que pertenece al paralelismo de nivel de instrucción (ILP). En comparación con la granularidad paralela de "nivel de transacción/nivel de cuenta" de Monad / MegaETH, el mecanismo de paralelismo de GatlingX pertenece a la ruta de optimización de nivel de instrucción, que está más cerca de la refactorización subyacente del motor de la máquina virtual. Actualmente se encuentra en la fase de concepto, con un documento técnico y un boceto arquitectónico publicados, y aún no hay SDK ni red principal.

  Artela propone un concepto de diseño diferenciado y paralelo. Con la introducción de la máquina virtual WebAssembly (WASM) de la arquitectura EVM++, los desarrolladores pueden agregar y ejecutar dinámicamente extensiones en la cadena utilizando el modelo de programación Aspect mientras mantienen la compatibilidad con EVM. Utiliza la granularidad de invocación del contrato (Función / Extensión) como la unidad paralela mínima y admite la inyección de módulos de extensión (similar al "middleware conectable") cuando se ejecuta el contrato EVM, para lograr el desacoplamiento lógico, la invocación asíncrona y la ejecución paralela a nivel de módulo. Se presta más atención a la componibilidad y la arquitectura modular de la capa de ejecución. El concepto proporciona nuevas ideas para aplicaciones complejas de varios módulos en el futuro.

  3. Cadena de arquitectura paralela nativa: El modelo de ejecución EVM de Ethereum, la ontología de ejecución de la VM reconstruida

  ,

  ha adoptado una arquitectura de un solo hilo de "orden de transacción completa + ejecución en serie" desde el comienzo de su diseño, con el objetivo de garantizar la certeza y consistencia de los cambios de estado para todos los nodos de la red. Sin embargo, esta arquitectura tiene un cuello de botella natural en el rendimiento, lo que limita el rendimiento y la escalabilidad del sistema. Por el contrario, las cadenas de arquitectura de computación paralela nativas, como Solana (SVM), MoveVM (Sui, Aptos) y Sei v2 basadas en el SDK de Cosmos, están diseñadas para la ejecución paralela desde el diseño subyacente y tienen las siguientes ventajas:

  • Modelos de separación natural de estados: Solana utiliza un mecanismo de declaración de bloqueo de cuenta, MoveVM introduce un modelo de propiedad de objetos y Sei v2 se basa en la clasificación de tipos de transacción. Se realiza el juicio de conflictos estáticos y se admite la programación simultánea a nivel de transacción.
  • Las máquinas virtuales están optimizadas para la simultaneidad: el motor Sealevel de Solana admite de forma nativa la ejecución multiproceso; MoveVM puede realizar análisis de gráficos de simultaneidad estática; Sei v2 integra un motor de coincidencia multiproceso con un módulo de VM paralelo.

  Por supuesto, este tipo de cadena paralela autóctona también se enfrenta al reto de la compatibilidad ecológica. Las arquitecturas que no son EVM suelen requerir nuevos lenguajes de desarrollo (como Move y Rust) y cadenas de herramientas, que tienen ciertos costes de migración para los desarrolladores. Además, los desarrolladores deben dominar una serie de conceptos nuevos, como los modelos de acceso con estado, los límites de simultaneidad, los ciclos de vida de los objetos, etc., que plantean requisitos más altos para comprender los umbrales y los paradigmas de desarrollo.

  3.1 El principio del motor paralelo a nivel del mar de Solana y SVM

  El modelo de ejecución Sealevel de Solana es un mecanismo de programación paralela de cuentas, que es el motor central utilizado por Solana para realizar la ejecución de transacciones paralelas dentro de la cadena, y logra una concurrencia de alto rendimiento a nivel de contrato inteligente a través del mecanismo de "declaración de cuenta + programación estática + ejecución multihilo". Sealevel es el primer modelo de ejecución en el campo de la cadena de bloques que implementa con éxito la programación concurrente dentro de la cadena en un entorno de producción, y sus ideas arquitectónicas han influido en muchos proyectos de computación paralela posteriores, y es un paradigma de referencia para el diseño paralelo de capa 1 de alto rendimiento.

  Mecanismo central:

  1. Listas de acceso explícito a la cuenta: Cada transacción debe declarar la cuenta involucrada (lectura/escritura) al enviarla, y el sistema determinará si hay un conflicto de estado entre las transacciones.

  2. Detección de conflictos y programación multihilo

  • Si no hay intersección entre los conjuntos de cuentas a los que acceden las dos transacciones→ se pueden ejecutar en paralelo;
  • Hay un conflicto→ que se ejecuta en serie en orden dependiente;
  • El programador asigna transacciones a diferentes subprocesos en función del gráfico de dependencias.

  3. Contexto de invocación del programa: Cada llamada de contrato se ejecuta en un contexto aislado sin una pila compartida para evitar interferencias entre llamadas.

  Sealevel es el motor de programación de ejecución paralela de Solana, mientras que SVM es un 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 despliega VMs de Solana en cadenas modulares como Ethereum L2 o Celestia, aprovechando el motor de ejecución paralela de Solana como capa de ejecución rollup. Eclipse es uno de los primeros proyectos en proponer separar la capa de ejecución de Solana (Sealevel + SVM) de la red principal de Solana y migrarla a una arquitectura modular, y la salida modular del "modelo de ejecución súper concurrente" de Solana es Execution Layer-as-a-Service, por lo que Eclipse también pertenece a la categoría de computación paralela.

  La ruta de Neon es diferente, introduce el EVM para operar en un entorno SVM / Sealevel. Cree una capa de tiempo de ejecución compatible con EVM, los desarrolladores pueden usar Solidity para desarrollar contratos y ejecutarlos en el entorno SVM, pero la ejecución de la programación usa SVM + Sealeve. Neon se inclina más hacia la categoría de Blockchain Modular que hacia la innovación de computación paralela.

  Con todo, Solana y las SVM se basan en el motor de ejecución Sealevel, y la filosofía de programación basada en el sistema operativo de Solana es similar al programador del kernel, que es rápido pero relativamente inflexible. Es una cadena pública nativa de computación paralela de alto rendimiento.

  3.2 Arquitectura MoveVM: Impulsada por Recursos y Objetos

  MoveVM es una máquina virtual de contrato inteligente diseñada para la seguridad de recursos en cadena y la ejecución paralela, y su lenguaje central, Move, fue desarrollado originalmente por Meta (anteriormente Facebook) para el proyecto Libra, enfatizando el concepto de "los recursos son objetos", y todos los estados en la cadena existen como objetos, con una propiedad y ciclos de vida claros. Esto permite a MoveVM analizar si hay conflictos de estado entre las transacciones durante el tiempo de compilación e implementar la programación paralela estática a nivel de objeto, que se usa ampliamente en cadenas públicas paralelas nativas como Sui y Aptos.

  Modelo de propiedad de objetos de SuiLas

  capacidades de computación paralela de Sui se derivan de su enfoque único para el modelado de estado y el análisis estático a nivel de lenguaje. A diferencia de las cadenas de bloques tradicionales, que utilizan árboles de estado globales, Sui ha construido un modelo centrado en objetos basado en el "objeto", que funciona con el sistema de tipo lineal de MoveVM para hacer 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 todo el estado de la cadena en objetos separados, cada uno con un ID único, un propietario claro (cuenta o contrato) y una definición de tipo. Estos objetos no comparten estado entre sí y están inherentemente aislados. El contrato debe declarar explícitamente la colección de objetos involucrados cuando se llama, evitando el problema de acoplamiento de estado del tradicional "árbol de estado global" en cadena. Este diseño divide el estado en cadena en varias unidades independientes, lo que hace que la ejecución simultánea 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 con el soporte del sistema de tipos lineales del lenguaje Move. Permite al sistema programar transacciones para que se ejecuten en paralelo inferiendo qué transacciones no tienen conflictos de estado a través de la propiedad de objetos antes de que se ejecuten. En comparación con la detección de conflictos y la reversión de los tiempos de ejecución tradicionales, el mecanismo de análisis estático de Sui reduce en gran medida la complejidad de la programación al tiempo que mejora la eficiencia de la ejecución, que es la clave para lograr un alto rendimiento y capacidades de procesamiento paralelo deterministas.

  Sui divide el espacio de estados objeto por objeto, combinado con el análisis de propiedad en tiempo de compilación, para lograr una ejecución paralela de nivel de objeto de bajo costo y sin reversión. En comparación con la ejecución en serie o la detección en tiempo de ejecución de las cadenas tradicionales, Sui ha logrado mejoras significativas en la eficiencia de la ejecución, el determinismo del sistema y la utilización de recursos.

  Mecanismo de ejecución Block-STM de AptosAptos

  es una cadena de bloques de capa 1 de alto rendimiento basada en el lenguaje Move, y su capacidad de ejecución paralela se deriva principalmente del marco de desarrollo propio Block-STM (memoria transaccional de software a nivel de bloque). A diferencia de la estrategia de Sui de "paralelismo estático en tiempo de compilación", Block-STM pertenece al mecanismo de programación dinámica de "concurrencia optimista en tiempo de ejecución + reversión de conflictos", que es adecuado para tratar con conjuntos de transacciones con dependencias complejas.

  Block-STM divide la ejecución de la transacción de un bloque en tres etapas:

  • Ejecución especulativa: Todas las transacciones están libres de conflictos de forma predeterminada antes de la ejecución, y el sistema programa las transacciones en paralelo a múltiples subprocesos para intentar ejecutarse simultáneamente, y registra el estado de la cuenta (conjunto de lectura/escritura) al que acceden.
  • Fase de validación: El sistema verifica el resultado de la ejecución: si hay un conflicto de lectura-escritura entre dos transacciones (por ejemplo, Tx1 lee el estado de escritura de Tx2), una de ellas se revierte.
  • Fase de reintento: las transacciones en conflicto se reprogramarán hasta que se resuelvan sus dependencias y, finalmente, todas las transacciones formen una secuencia válida y determinista de envíos de estado.

  Block-STM es un modelo de ejecución dinámica de "paralelismo optimista + retroceso y reintentos", que es adecuado para escenarios de procesamiento por lotes de transacciones en cadena lógicamente complejos y con uso intensivo de estado, y es el núcleo de computación paralela para que Aptos construya una cadena pública de alta versatilidad y alto rendimiento.

  Solana es una escuela de programación de ingeniería, más como un "kernel del sistema operativo", adecuado para límites de estado claros, comercio de alta frecuencia controlable, es un estilo de ingeniero de hardware, para ejecutar la cadena como hardware (ejecución paralela de grado de hardware); Aptos es un sistema tolerante a fallos, más parecido a un "motor de concurrencia de bases de datos", adecuado para sistemas de contrato con un fuerte acoplamiento de estado y cadenas de llamadas complejas. Aptos y Sui son como ingenieros de lenguajes de programación, y la seguridad de los recursos de grado de software representa la ruta de implementación técnica de la computación paralela Web3 bajo diferentes filosofías.

  3.3 Cosmos SDK Parallel Scaling

  Sei V2 es una cadena pública transaccional de alto rendimiento construida sobre la base del SDK de Cosmos, y su capacidad de paralelismo se refleja principalmente en dos aspectos: el motor de coincidencia multiproceso (Parallel Matching Engine) y la optimización de la ejecución paralela de la capa de máquina virtual, que está diseñada para servir escenarios de transacciones en cadena de alta frecuencia y baja latencia, como DEX de libro de órdenes, infraestructura de intercambio en la cadena, etc.

  Mecanismo de paralelismo central:

  1. Motor de coincidencia paralela: SEI V2 introduce una ruta de ejecución de subprocesos múltiples en la lógica de coincidencia de órdenes, dividiendo el libro de órdenes pendientes y la lógica de coincidencia a nivel de subproceso, de modo que las tareas de coincidencia entre múltiples pares comerciales se puedan procesar en paralelo y evitar el cuello de botella de un solo hilo.
  2. Optimización de la simultaneidad a nivel de máquina virtual: Sei V2 crea un entorno de tiempo de ejecución de CosmWasm con capacidades de ejecución simultánea, lo que permite que algunas llamadas de contrato se ejecuten en paralelo sin conflictos de estado y coopera con el mecanismo de clasificación de tipos de transacción para lograr un mayor control de rendimiento.
  3. Consenso paralelo y programación de la capa de ejecución: Se introduce el llamado mecanismo de consenso "Twin-Turbo" para fortalecer el rendimiento y el desacoplamiento entre la capa de consenso y la capa de ejecución, y mejorar la eficiencia general del procesamiento de bloques.

  3.4 Reformador del modelo UTXO Fuel Fuel es

  una capa de ejecución de alto rendimiento diseñada en base a la arquitectura modular de Ethereum, y su mecanismo central de paralelismo se deriva del modelo UTXO (Unspent Transaction Output) mejorado. A diferencia del modelo de cuenta de Ethereum, Fuel utiliza una estructura UTXO para representar activos y estados, que está inherentemente aislada por estado, lo que facilita la determinación de qué transacciones se pueden ejecutar de forma segura en paralelo. Además, Fuel presenta su lenguaje de contratos inteligentes de desarrollo propio, Sway (similar a Rust), combinado con herramientas de análisis estático, para determinar los conflictos de entrada antes de que se ejecuten las transacciones, con el fin de lograr una programación paralela eficiente y segura a nivel de transacción. Es una capa de ejecución alternativa a EVM que equilibra el rendimiento y la modularidad.

  4. Modelo de actor: un nuevo paradigma de ejecución concurrente de

  agentes El modelo de actor es un paradigma de ejecución paralela basado en agente o proceso, que es diferente de la computación sincrónica tradicional del estado global en la cadena (Solana/Sui/Monad y otros escenarios de "computación paralela en la cadena"), que enfatiza que cada agente tiene un estado y comportamiento independientes, y se comunica y programa a través de mensajes asíncronos. Bajo esta arquitectura, el sistema en cadena puede ser ejecutado simultáneamente por un gran número de procesos que están desacoplados entre sí, y tiene una fuerte escalabilidad y tolerancia a fallos asíncronos. Entre los proyectos representativos se encuentran AO (Arweave AO), ICP (Internet Computer) y Cartesi, que están impulsando la evolución de la cadena de bloques de un motor de ejecución a un "sistema operativo en cadena", proporcionando una infraestructura nativa para agentes de IA, interacciones multitarea y orquestación lógica compleja.

  Si bien el diseño del modelo de actor es similar a la fragmentación en términos de características superficiales (por ejemplo, paralelismo, aislamiento de estado y procesamiento asincrónico), los dos representan esencialmente caminos técnicos y filosofías de sistema completamente diferentes. El modelo de actor hace hincapié en la "computación asíncrona multiproceso", en la que cada agente se ejecuta de forma independiente, mantiene el estado de forma independiente e interactúa de forma basada en mensajes. La fragmentación, por otro lado, es un mecanismo de "fragmentación horizontal de estado y consenso", que divide toda la cadena de bloques en múltiples subsistemas (fragmentos) que procesan las transacciones de forma independiente. Los modelos de actor se parecen más a un "sistema operativo de agente distribuido" en el mundo de la Web3, mientras que la fragmentación es una solución de escalado estructural para las capacidades de procesamiento de transacciones en cadena. Ambos logran el paralelismo, pero tienen diferentes puntos de partida, objetivos y arquitecturas de ejecución.

  4.1 AO (Arweave), una computadora superparalela en la parte superior de la capa de almacenamientoAO

  es una plataforma de computación descentralizada que se ejecuta en la capa de almacenamiento permanente de Arweave, con el objetivo principal de construir un sistema operativo en cadena que admita la operación de agentes asíncronos a gran escala.

  Características principales de la arquitectura:

  • Arquitectura de procesos: Cada agente se denomina proceso, con estado independiente, programador independiente y lógica de ejecución;
  • Sin estructura de cadena de bloques: AO no es una cadena, sino una capa de almacenamiento descentralizada + motor de ejecución basado en mensajes multiagente basado en Arweave;
  • Sistema de programación de mensajes asíncronos: los procesos se comunican entre sí a través de mensajes, adoptan un modelo de operación asincrónica sin bloqueos y, naturalmente, admiten la expansión simultánea.
  • Almacenamiento de estado permanente: Todos los estados de los agentes, los registros de mensajes y las instrucciones se registran permanentemente en Arweave, lo que garantiza una auditabilidad total y una transparencia descentralizada.
  • Nativo del agente: Es adecuado para implementar tareas complejas de varios pasos (como agentes de IA, controladores de protocolo DePIN, orquestadores automáticos de tareas, etc.) y puede construir un "coprocesador de IA en cadena".

  AO toma la ruta definitiva de "agente nativo + controlador de almacenamiento + arquitectura sin cadena", enfatizando la flexibilidad y el desacoplamiento de módulos, y es un "marco de microkernel en la cadena construido sobre la capa de almacenamiento", con el límite del sistema disminuyendo deliberadamente, enfatizando la computación liviana + estructura de control componible.

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

  es una plataforma de aplicaciones en cadena nativa de Web3 lanzada por DFINITY, con el objetivo de ampliar la potencia informática en cadena a experiencias similares a Web2 y admitir alojamiento de servicios completos, enlace de nombres de dominio y arquitectura sin servidor.

  Características principales de la arquitectura:

  • Arquitectura de contenedor (contenedores como agentes): cada contenedor es un agente que se ejecuta en una máquina virtual Wasm con capacidades independientes de estado, código y programación asincrónica;
  • Sistema de consenso distribuido de subred (subred): toda la red consta de varias subredes, cada una de las cuales mantiene un conjunto de contenedores y alcanza el consenso a través del mecanismo de firma BLS.
  • Modelo de invocación asincrónica: Canister se comunica con Canister a través de mensajes asincrónicos, admite la ejecución sin bloqueo y tiene un paralelismo natural.
  • Alojamiento web en cadena: Admite contratos inteligentes para alojar directamente páginas de front-end, mapeo de DNS nativo y es la primera plataforma de blockchain que admite navegadores para acceder directamente a dApps;
  • El sistema tiene funciones completas: tiene API del sistema como actualización en caliente en cadena, autenticación de identidad, aleatoriedad distribuida y temporizador, que es adecuado para la implementación compleja de servicios en cadena.

  ICP elige un paradigma de sistema operativo de plataforma pesada, empaquetado integrado y fuerte control de plataforma, y tiene un "sistema operativo blockchain" que integra consenso, ejecución, almacenamiento y acceso, enfatizando las capacidades completas de alojamiento de servicios y expandiendo el límite del sistema a una plataforma de alojamiento Web3 de pila completa.

  Además, los proyectos de computación paralela de otros paradigmas del Modelo de Actor se pueden consultar en la siguiente tabla:

  

  5. Resumen y perspectivaSobre

  la base de las diferencias entre la arquitectura de máquina virtual y el sistema de lenguaje, las soluciones de computación paralela de blockchain se pueden dividir aproximadamente en dos categorías: cadena de mejora paralela EVM y cadena de arquitectura paralela nativa (no EVM).

  Sobre la base de mantener la compatibilidad del ecosistema EVM/Solidity, el primero logra un mayor rendimiento y capacidades de procesamiento paralelo a través de una optimización en profundidad de la capa de ejecución, lo cual es adecuado para escenarios que desean heredar activos y herramientas de desarrollo de Ethereum y lograr avances en el rendimiento al mismo tiempo. Los proyectos representativos incluyen:

  • Monad: Implementa un modelo de ejecución paralela optimista compatible con EVM a través de la escritura diferida y la detección de conflictos en tiempo de ejecución, construye gráficos de dependencias y programa la ejecución después de que se complete el consenso.
  • MegaETH: abstrae cada cuenta/contrato en una micro-VM independiente e implementa una programación paralela a nivel de cuenta altamente desacoplada basada en mensajería asíncrona y gráficos dependientes del estado.
  • Pharos: Cree una arquitectura de malla acumulativa para lograr el procesamiento paralelo a nivel de sistema en todos los procesos a través de canalizaciones asíncronas y módulos SPN.
  • Reddio: Utiliza la arquitectura zkRollup + GPU para acelerar el proceso de verificación fuera de la cadena de zkEVM a través de la generación de SNARK por lotes y mejorar el rendimiento de la verificación.

  Este último se deshace por completo de las limitaciones de la compatibilidad de Ethereum y rediseña el paradigma de ejecución de la máquina virtual, el modelo de estado y el mecanismo de programación para lograr una concurrencia nativa de alto rendimiento. Las subclases típicas incluyen:

  • Solana (SVM): un modelo de ejecución paralela a nivel de cuenta basado en notificaciones de acceso a cuentas y programación de gráficos de conflictos estáticos;
  • Sui / Aptos (sistema MoveVM): Basado en el modelo de objetos de recursos y el sistema de tipos, admite el análisis estático en tiempo de compilación y realiza el paralelismo a nivel de objeto.
  • Sei V2 (ruta del SDK de Cosmos): presenta un motor de coincidencia multiproceso y optimización de la simultaneidad de máquinas virtuales en la arquitectura de Cosmos, que es adecuado para aplicaciones transaccionales de alta frecuencia.
  • Fuel (arquitectura UTXO + Sway): Paralelismo a nivel de transacción a través del análisis estático del conjunto de entrada UTXO, combinando una capa de ejecución modular con un lenguaje de contrato inteligente personalizado Sway;

  Además, como un sistema paralelo más generalizado, el modelo de actor construye un paradigma de ejecución en cadena de "operación independiente de múltiples agentes + colaboración basada en mensajes" a través de un mecanismo de programación de procesos asíncrono basado en Wasm o máquinas virtuales personalizadas. Los proyectos representativos incluyen:

  • AO (Arweave AO): Construcción de un sistema de microkernel asíncrono en cadena basado en el tiempo de ejecución del agente impulsado por almacenamiento persistente;
  • ICP (Internet Computer): utiliza el agente en contenedor (Canister) como la unidad más pequeña para lograr una ejecución asíncrona y altamente escalable a través de la coordinación de subredes.
  • Cartesi: Presenta el sistema operativo Linux como un entorno informático fuera de la cadena para proporcionar una ruta de verificación en la cadena para resultados informáticos confiables, adecuada para escenarios de aplicaciones complejas o que requieren muchos recursos.

  Basándonos en la lógica anterior, podemos resumir el esquema actual de la cadena pública de computación paralela en una estructura de clasificación como se muestra en la siguiente figura:

  

  Desde una perspectiva de escalado más amplia, la fragmentación y el rollup (L2) se centran en el escalado horizontal a través de la fragmentación de estado o la ejecución fuera de la cadena, mientras que las cadenas de computación paralela (por ejemplo, Monad, Sui, Solana) y los sistemas orientados a actores (por ejemplo, AO, ICP) reconstruyen directamente el modelo de ejecución y logran un paralelismo nativo dentro de la cadena o en la capa del sistema. El primero mejora el rendimiento dentro de la cadena a través de máquinas virtuales multihilo, modelos de objetos, análisis de conflictos de transacciones, etc.; Este último toma el proceso/agente como unidad básica y adopta modos de ejecución asincrónicos y basados en mensajes para lograr una operación concurrente de múltiples agentes. Por el contrario, la fragmentación y los rollups se parecen más a "dividir la carga en varias cadenas" o "externalizar fuera de la cadena", mientras que el modelo de cadena y actor paralelo es "liberar el potencial de rendimiento del propio motor de ejecución", lo que refleja una evolución arquitectónica más completa.

  Computación paralela vs Arquitectura de particionamiento vs Escalado acumulativo vs Comparación de rutas de escalado orientado a actores

  

  Cabe señalar que la mayoría de las cadenas de arquitectura paralela nativas han entrado en la etapa de lanzamiento de la red principal, aunque el ecosistema general de desarrolladores aún es difícil de comparar con el sistema Solidity del sistema EVM, pero los proyectos representados por Solana y Sui, con su arquitectura de ejecución de alto rendimiento y la prosperidad gradual de las aplicaciones ecológicas, se han convertido en las cadenas públicas centrales a las que el mercado presta gran atención.

  Por el contrario, aunque el ecosistema Ethereum Rollup (L2) ha entrado en la etapa de "10,000 cadenas a la vez" o incluso de "sobrecapacidad", la actual cadena de mejora paralela de EVM convencional todavía se encuentra generalmente en la etapa de red de prueba y aún no ha sido verificada por el entorno real de la red principal, y su capacidad de escalado y estabilidad del sistema aún deben probarse más. Queda por ver si estos proyectos pueden mejorar significativamente el rendimiento de EVM e impulsar saltos ecológicos sin sacrificar la compatibilidad, o si pueden diferenciar aún más la liquidez y los recursos de desarrollo de Ethereum.