TL;DR

1. 1. Varios de los principales VCs, incluidos Paradigm, Jump y Dragonfly, están invirtiendo en el concepto de EVM Paralela.
2. 1. Los proyectos representativos en este dominio incluyen Monad, Sei, MegaETH, Polygon, Neon EVM y BSC, que operan tanto en soluciones de Capa 1 (L1) como de Capa 2 (L2).
3. 1. Sin embargo, hay información pública limitada disponible sobre las diferencias específicas entre los equipos.
4. 1. Si bien “paralelización” es el significado literal de Parallel EVM, denota una optimización especializada destinada a mejorar varios aspectos del rendimiento de EVM, potencialmente empujando los límites de las capacidades de EVM.
5. 1. Los desafíos incluyen la necesidad de refactorizar toda la pila de tecnología y abordar problemas como predecir conflictos entre transacciones paralelas y manejar eficientemente los conflictos si surgen.
6. 1. Otro desafío es establecer diferenciación en el ecosistema de código abierto mientras se equilibra la descentralización con el rendimiento.

Después de una extensa investigación e iteración en algoritmos de consenso, capas de datos (DA) y tecnología de prueba de conocimiento cero, la atención se ha centrado en la próxima frontera en tecnología hardcore: EVM paralelo. Esta tendencia ya ha atraído una inversión significativa del mercado de capitales, con cientos de millones de dólares siendo invertidos en el desarrollo de varias startups de nivel unicornio.

El foco en Parallel EVM, también conocido como paralelización de EVM, se intensificó cuando Georgios Konstantopoulos, CTO de Paradigm, y Haseeb Qureshi de Dragonfly resaltaron este concepto coincidentemente a finales de 2023 mientras discutían las tendencias futuras para 2024. A pesar de esta atención, las discusiones detalladas sobre el tema han sido escasas, lo que ha llevado a muchos a descartarlo como algo particularmente novedoso. Dado que tanto la Máquina Virtual Ethereum (EVM) como la computación paralela son conceptos bien establecidos, lo que eleva la fusión de estos dos términos al estatus de una tendencia emergente importante sigue sin estar claro.

Sin embargo, Parallel EVM sigue siendo un tema altamente especializado. Es notable que en los resúmenes anuales y pronósticos de tendencias de numerosas instituciones de investigación, Parallel EVM no recibe mención. En consecuencia, sigue siendo un concepto incipiente que carece de un consenso generalizado. Además, al igual que conceptos como algoritmos de consenso y aplicaciones descentralizadas (DA), Parallel EVM es inherentemente técnico, lo que limita su audiencia a un alcance aún más estrecho.

El principal beneficio de Parallel EVM radica en su capacidad para potenciar a las aplicaciones descentralizadas existentes y lograr niveles de rendimiento similares a los de Internet. De hecho, se podría argumentar que Parallel EVM se destaca como una tecnología novedosa capaz de aprovechar una amplia gama de contratos inteligentes establecidos, al mismo tiempo que logra un alto rendimiento y un alto rendimiento paralelo en cadenas públicas.

Paradigm ha estado esperando entrar en el juego durante mucho tiempo, Jump está fuertemente invertido

“Fortune” informa que Paradigm tiene la intención de liderar la última ronda de financiación para Monad, con el objetivo de recaudar $200 millones con una valoración de $3 mil millones. Si bien esto marca la primera incursión de Paradigm en respaldar a un equipo con un concepto de EVM Paralelo, han estado siguiendo de cerca esta tecnología durante varios años. Georgios Konstantopoulos, CTO de Paradigm, mencionó este término por primera vez en 2021.

La etimología de “Monad” agrega otra capa de intriga. En el sistema del filósofo Leibniz, Monad significa el elemento fundamental que constituye el universo. Estas entidades indivisibles permanecen imperviables a las influencias físicas, reflejando cada una la totalidad del universo, conocido como “单子” en chino.

En el ámbito de la informática, Monad sirve como un patrón de diseño dentro de los lenguajes de programación funcional, ayudando a los programadores a navegar por complejidades del mundo real con una precisión casi matemática. Este enfoque fomenta la modularidad del código, la comprensión y el mantenimiento.

Un detalle digno de mención es la simetría lingüística entre Monad y Nomad, este último denota un vagabundo, y "nómada digital" hace referencia a un vagabundo en el ámbito digital.

Georgios, en su discurso sobre el tema, también hizo referencia a Sei y Polygon. Sin embargo, su optimismo hacia Parallel EVM se ve reforzado por el desarrollo de Reth, un cliente de Ethereum diseñado por Paradigm. Posicionado como un cliente de capa de ejecución de Ethereum de alto rendimiento construido en Rust, Reth está avanzando rápidamente y recientemente ha pasado a la etapa Beta. Si bien se considera la perspectiva de integrar Parallel EVM directamente en Reth, el considerable esfuerzo de ingeniería involucrado sugiere que apoyar Parallel EVM a través de inversiones en otros equipos podría ser una opción más viable. La documentación de Monad revela su uso predominante de C++ y Rust en sus esfuerzos de ingeniería.

Tras la creación de Reth, surgieron acusaciones por parte de miembros del equipo de Erigon, alegando plagio de su código abierto, Akula, lo que llevó a una disminución de fondos para el proyecto Akula. Georgios refutó estas afirmaciones, asegurando que Reth no es ni un derivado ni un fork de ningún otro cliente, aunque se inspira en Geth, Erigon y Akula.

Otro jugador clave es Jump Trading y Jump Capital, con el fundador de Monad procedente de Jump Trading, contando con una amplia experiencia en el trading de alta frecuencia. Sei cuenta con Jump Capital entre sus inversores, con la participación de Jump extendiéndose profundamente en el ecosistema de Solana, abarcando infraestructura y proyectos.

Dragonfly, un inversor temprano en Monad, también ha mantenido un ojo agudo en los desarrollos relacionados, con inversiones en NEAR, centrándose en la tecnología de fragmentación, junto con Aptos, Avalanche, Nervos y otras cadenas públicas.

Actualizar algoritmos de consenso no es suficiente, finalmente le toca a la capa de ejecución

En las recientes batallas entre cadenas públicas, el foco ha pasado consistentemente por alto la capa de ejecución, en lugar de fijarse casi exclusivamente en algoritmos de consenso innovadores, ya sea Solana, Avalanche, o EOS, entre otros. A pesar de las innovaciones significativas en la capa de ejecución por parte de estas cadenas, la comunidad tiende a recordar principalmente sus algoritmos de consenso empleados. Además, hay una noción predominante dentro de la comunidad de que el rendimiento superior de estas cadenas públicas de alto rendimiento proviene únicamente de sus algoritmos de consenso revolucionarios.

Sin embargo, lograr una cadena pública de alto rendimiento requiere una relación simbiótica entre el algoritmo de consenso y la capa de ejecución, haciendo eco del principio de que una cadena es tan fuerte como su eslabón más débil. Las cadenas públicas que dependen de la Máquina Virtual Ethereum (EVM) y se centran únicamente en mejorar su algoritmo de consenso se enfrentan a cuellos de botella de rendimiento que exigen nodos cada vez más robustos. Tome, por ejemplo, Binance Smart Chain (BSC), que limita el procesamiento de Gas de bloque a 2000 transacciones por segundo (TPS). Para respaldar esto, las configuraciones de los nodos deben superar en varios múltiplos a las de un nodo completo de Ethereum. Si bien Polygon teóricamente cuenta con una capacidad de 1000 TPS, normalmente solo logra decenas a cientos.

Los nodos de archivo de BSC requieren un mínimo de CPUs de 16 núcleos y 128 GB de memoria, en comparación con los nodos de Ethereum, que requieren al menos CPUs de 4 núcleos y 16 GB de memoria.

Reconociendo estos desafíos, el equipo de BSC ha entrado en colaboración con NodeReal para desarrollar la tecnología EVM Paralela. Esta innovación tiene como objetivo mejorar aún más la capacidad de procesamiento de transacciones por bloque mediante la ejecución de transacciones en paralelo, aumentando consecuentemente el límite superior de TPS.

Paralelo: Actualización de una CPU de un solo núcleo a una CPU multinúcleo

En la mayoría de los sistemas blockchain, las transacciones siguen un estricto orden secuencial, similar a una CPU de un solo núcleo donde cada cálculo debe esperar a que termine el anterior. A pesar de su simplicidad y baja complejidad del sistema, este enfoque es relativamente lento.

Sin embargo, a medida que los sistemas de blockchain del futuro apuntan a dar cabida a bases de usuarios a escala de Internet, depender únicamente de una CPU de un solo núcleo resulta insuficiente. Por lo tanto, la transición a una CPU multinúcleo con máquinas virtuales paralelizadas permite el procesamiento simultáneo de múltiples transacciones, lo que aumenta la capacidad de procesamiento. Sin embargo, la implementación de esta actualización presenta numerosos desafíos, como la gestión de conflictos cuando dos transacciones procesadas concurrentemente intentan modificar el mismo contrato inteligente. Abordar esto requiere el desarrollo de mecanismos novedosos.

Para contratos inteligentes no relacionados ejecutados en paralelo, el rendimiento puede aumentarse aún más escalando según el número de hilos de procesamiento concurrentes. Además, Parallel EVM no solo aumenta las capacidades paralelas, sino que también mejora la eficiencia de la ejecución de un solo hilo. Keone Hon, CEO de Monad, resaltó que el cuello de botella principal de EVM radica en las lecturas y escrituras frecuentes de estados. Él hizo hincapié en que si bien la ejecución paralela es un aspecto fundamental del plan de trabajo, el objetivo principal de Monad es optimizar la eficiencia de EVM al máximo.

Por lo tanto, si bien Parallel EVM implica inherentemente la "paralelización", principalmente sirve como una optimización especializada del rendimiento de varios componentes de EVM. En consecuencia, sus esfuerzos probablemente delimiten los límites de rendimiento dentro del estándar EVM.

EVM no es igual a Solidity

Escribir contratos inteligentes es una habilidad vital para los desarrolladores de blockchain, que requiere la capacidad de implementar lógica basada en requisitos empresariales utilizando Solidity u otros lenguajes de alto nivel. Sin embargo, la Máquina Virtual Ethereum (EVM) no comprende directamente la lógica de Solidity; requiere traducción a bytecode de bajo nivel para su ejecución. Los desarrolladores de Solidity suelen depender de herramientas existentes para manejar este proceso de traducción.

Esta traducción conlleva gastos generales, pero los ingenieros familiarizados con el código de bajo nivel pueden evitarlo codificando directamente la lógica utilizando opcodes en Solidity, lo que resulta en una eficiencia óptima y ahorros de gas para las transacciones de usuario. Por ejemplo, el protocolo Seaport de Opensea aprovecha extensamente el ensamblaje en línea en contratos inteligentes para minimizar los costos de gas para los usuarios.

La posible implementación de Parallel EVM promete no solo la introducción de capacidades paralelas, sino también la optimización del rendimiento general de la pila EVM. Este avance aliviaría la necesidad de que los desarrolladores de aplicaciones dediquen esfuerzos significativos a la optimización de gas, ya que la máquina virtual subyacente ya gestionaría eficientemente tales diferencias.

Diferencias en el rendimiento de EVM, “Estándar” no es igual a “Práctica de ingeniería”

El motor donde los contratos inteligentes se compilan en opcodes y se procesan a menudo se conoce como la "capa de ejecución" o "máquina virtual". El bytecode establecido por la Máquina Virtual Ethereum (EVM) ha surgido como una norma de la industria. Ya sea en las redes de capa 2 de Ethereum u otras cadenas públicas independientes, la compatibilidad con el estándar EVM es muy favorecida. Los desarrolladores se benefician de la capacidad de escribir un contrato inteligente una vez e implementarlo en múltiples redes, lo que resulta en ahorros de costos considerable.

Aunque la adhesión al estándar de bytecode de EVM califica a un sistema como compatible con EVM, los métodos de implementación pueden variar significativamente. Por ejemplo, el cliente Ethereum Geth emplea el lenguaje Go para implementar el estándar de EVM, mientras que el equipo de investigación de la Fundación Ethereum, Ipsilon, mantiene una implementación independiente de EVM desarrollada en C++. Otros clientes de Ethereum pueden utilizar directamente esta implementación como motor de ejecución de EVM.

De manera análoga, varias industrias se adhieren a normas internacionales para sus productos. Por ejemplo, un producto debe cumplir con un umbral especificado de recuento bacteriano antes de que pueda ser vendido, lo que representa la "norma". Sin embargo, las fábricas individuales pueden emplear diversos métodos de esterilización para cumplir con este requisito, optando algunas por enfoques más rentables, ejemplificando la "práctica".

La existencia de implementaciones como evmone indica la viabilidad de enfoques alternativos. En consecuencia, dentro del contexto de EVM, el estándar delinea operaciones fundamentales de bytecode (por ejemplo, funciones aritméticas básicas como suma, resta, multiplicación), cada bytecode produciendo salidas específicas en función de las entradas definidas. Si bien la conformidad con este estándar es esencial, las metodologías empleadas en la práctica pueden variar ampliamente, presentando un amplio margen para la personalización y las optimizaciones de ingeniería.

Similitudes y diferencias del EVM paralelo

En la pista Paralela EVM, además del ampliamente conocido Monad, otros contendientes prominentes incluyen Sei, MegaETH, Polygon, Neon EVM, BSC y el cliente Reth de Paradigm, que también se esfuerza por integrar la paralelización.

En cuanto a su posicionamiento, Monad, Sei, Polygon y BSC se clasifican como blockchains de Capa 1, mientras que MegaETH podría funcionar potencialmente como una solución de Capa 2, y Neon EVM opera dentro del marco de la red Solana. Además, Reth se destaca como un cliente de código abierto, con MegaETH preparado para continuar su desarrollo utilizando ciertos aspectos de la ingeniería de Reth.

Naturalmente, existe competencia entre estos equipos, y las especificaciones técnicas completas y la documentación de ingeniería aún no se han revelado completamente. Más comparaciones tendrán que esperar revelaciones gradualmente en el futuro. Esta dinámica puede parecerse a una carrera armamentista similar a los desarrollos vistos en la Capa 2 de BTC, Restaking y la Capa 2 de Ethereum. A pesar de las distinciones técnicas matizadas y la naturaleza de código abierto de estos proyectos, el factor crucial radica en establecer la distintividad de cada ecosistema.

Desafíos técnicos de EVM paralelo

El cuello de botella en transacciones ejecutadas de forma secuencial proviene de operaciones de CPU y del proceso de lectura y escritura de estados. Sin embargo, este método ofrece simplicidad, precisión y la capacidad de ejecutar transacciones paso a paso. Por el contrario, las máquinas virtuales ejecutadas en paralelo pueden encontrarse con conflictos de estados, lo que requiere controles adicionales antes o después de la ejecución.

Considere un escenario donde una máquina virtual admite cuatro hilos para ejecución paralela, con cada hilo capaz de procesar una transacción simultáneamente. Si las cuatro transacciones involucran el mismo grupo de transacciones en Uniswap, la computación paralela es inviable debido al impacto potencial en el precio de transacción del grupo. Sin embargo, si estos hilos manejan tareas completamente no relacionadas, la ejecución paralela no presenta ningún problema.

Abordar posibles conflictos después de la ejecución en paralelo requiere un módulo dedicado para la detección de conflictos y la reejecución si surgen conflictos. Además, la detección preventiva de transacciones potencialmente conflictivas puede fortalecer la eficiencia en paralelo general de la máquina virtual.

Aparte de las implementaciones de ingeniería específicas para Parallel EVM, los equipos suelen centrarse en rediseñar y optimizar el rendimiento de lectura/escritura de la base de datos de estado. Además, diseñan algoritmos de consenso como Monad's MonadDb y MonadBFT.

Desafíos

Para Parallel EVM, surgen dos posibles desafíos: la captura de valor de ingeniería a largo plazo por Ethereum y la centralización de nodos.

Actualmente, varios equipos se encuentran en las fases de desarrollo y pruebas de la tecnología Paralela EVM, sin que ninguno opte por abrir todavía todos los detalles de ingeniería, lo que constituye un obstáculo actual. Sin embargo, tras su integración en la red de prueba y la red principal, estas especificaciones de ingeniería se harán públicas y podrían integrarse potencialmente por Ethereum u otras cadenas públicas. En consecuencia, surge la necesidad de acelerar el desarrollo del ecosistema y establecer barreras adicionales a nivel del ecosistema.

Sin embargo, este problema no supone un obstáculo insalvable. Por un lado, los desarrolladores de criptomonedas ahora tienen una amplia gama de licencias de código abierto para elegir (como el modelo de licencia de Uniswap, que permite la divulgación de código pero restringe el bifurcamiento en proyectos comerciales). Por otro lado, la posición de Monad difiere de la de Ethereum. Incluso si Ethereum logra la finalidad de un solo espacio (SSF) en el futuro, la finalidad de la transacción sigue siendo de al menos 12 segundos, lo que es insuficiente para casos de uso de alta frecuencia.

Otro desafío compartido entre las cadenas públicas de alto rendimiento es la implementación de nodos adicionales para satisfacer los requisitos fundamentales de permisividad y falta de confianza del usuario: descentralización. Puede ser posible cuantificar ciertas métricas, como "TPS dividido por requisitos de hardware de nodo," permitiendo un análisis comparativo para determinar qué cadena/cliente pública ofrece un mayor TPS bajo requisitos de hardware específicos. En última instancia, requisitos de hardware más bajos para los nodos facilitan una mayor implementación de nodos.

Avanzando, continuaremos monitoreando el progreso de varios proyectos asociados con Parallel EVM y profundizaremos en sus tecnologías y discrepancias en detalle.

Descargo de responsabilidad：

1. Este artículo ha sido reimpreso de [GateInvestigación de ChainFeeds], Todos los derechos de autor pertenecen al autor original [ZHIXIONG PAN]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones y puntos de vista expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.