¿Cuál es el significado de la paralelización de EVM? ¿O es el final bajo la hegemonía del EVM?

TL;DR

• Varios VC líderes están apostando por el concepto Parallel EVM: Paradigm, Jump, Dragonfly, etc.
• El proyecto representativo es Monad, y también están Sei, MegaETH, Polygon, Neon EVM, BSC, etc. Algunos son L1, otros son L2. No hay información pública completa sobre las diferencias específicas entre los equipos.
• Aunque Parallel EVM significa literalmente “paralelización”, en realidad es una optimización especial del rendimiento de cada componente de EVM, por lo que es probable que sus esfuerzos representen el límite de rendimiento según el estándar EVM.
• Dificultad: además de reconstruir toda la pila de tecnología, también existe cómo predecir de antemano si las transacciones paralelas entrarán en conflicto y la eficiencia de la reejecución después de encontrar conflictos.
• Desafío: Cómo construir diferenciación en el ecosistema de código abierto y cómo encontrar un equilibrio entre descentralización y rendimiento.

Después de que el algoritmo de consenso, la DA (capa de datos) y la tecnología de prueba de conocimiento cero se hayan estudiado e iterado ampliamente, la siguiente tecnología fundamental que ha llamado la atención es Parallel EVM, en la que el mercado de capitales también ha invertido cientos de millones de dólares. narrativa y han nacido muchas tecnologías únicas: una startup a nivel de bestia.

La comunidad comenzó a prestar atención a Parallel EVM (paralelización EVM), que se originó a partir de la misma palabra clave mencionada por Georgios Konstantopoulos (CTO de Paradigm) y Haseeb Qureshi de Dragonfly cuando esperaban las tendencias de 2024 a finales de 2023. Sin embargo, no hay muchos detalles sobre este tema y mucha gente cree que no es un concepto nuevo. EVM y computación paralela son conceptos relativamente maduros respectivamente. ¿Por qué es una tendencia importante combinar estas dos palabras? ¿Paño de lana?

Pero este sigue siendo un tema muy específico, hasta el punto de que si nos fijamos en los resúmenes anuales y los pronósticos de tendencias de muchas instituciones de investigación, Parallel EVM no se menciona. Por tanto, este es todavía un concepto nuevo que aún no ha formado un consenso a gran escala. Además, este concepto es similar a temas como el algoritmo de consenso y DA: todos están puramente relacionados con la tecnología, por lo que hay incluso menos personas que le prestan atención.

La ventaja más directa de Paralle EVM es permitir que las aplicaciones descentralizadas existentes alcancen un rendimiento a nivel de Internet. Incluso se puede decir que Parallel EVM es la única tecnología nueva que no solo puede utilizar (una gran cantidad de contratos inteligentes maduros) existentes, sino también lograr un rendimiento de cadena pública paralelizado de alto rendimiento.

Paradigm ha estado esperando ingresar al juego durante mucho tiempo y Jump está apostando fuerte.

Según Fortune, Paradigm planea liderar la última ronda de inversión de Monad, recaudando 200 millones de dólares con una valoración de 3 mil millones de dólares. Aunque este es el primer concepto de equipo Parallel EVM en el que Paradigm planea invertir, en realidad han estado prestando atención a esta tecnología durante muchos años. Georgios Konstantopoulos (CTO de Paradigm) mencionó este término en 2021.

También es interesante el origen de la palabra mónada. En el sistema filosófico del filósofo Leibniz, las Mónadas son los elementos básicos que constituyen el universo. Son entidades indivisibles que no se ven afectadas por la física. Cada Mónada refleja el universo entero y alguna vez fue traducida como “mónada” en chino.

En informática, Monad es un patrón de diseño en lenguajes de programación funcionales que ayuda a los programadores a lidiar con la complejidad del mundo real con pureza casi matemática, haciendo que el código sea más modular, más fácil de entender y mantener.

Otra cosa interesante es que Monad y Nomad son “anagramas” entre sí. Nomad se refiere a nómada y nómada digital se refiere a nómada digital/pastor digital.

Además de Monads, Georgios también mencionó a Sei y Polygon al discutir este tema. Sin embargo, otra razón importante por la que es tan optimista acerca de Parallel EVM es que han desarrollado un cliente Ethereum, Reth. Se posiciona como un cliente de capa de ejecución Ethereum de alto rendimiento, implementado en lenguaje Rust. Reth se está desarrollando a un ritmo rápido y acaba de entrar en la etapa Beta. Tal vez consideren implementar Parallel EVM directamente en Reth, pero considerando la cantidad de ingeniería de I + D, puede ser una mejor opción invertir en otros equipos para promover Parallel EVM. Según la documentación de Monad, utilizan principalmente C++ y Rust en ingeniería.

Cuando se lanzó Reth, los miembros del equipo de Erigon también lo acusaron de plagiar su código fuente abierto Akula, lo que también provocó que el proyecto Akula careciera de fondos y detuviera el desarrollo. Georgios respondió que Reth no es una bifurcación de ningún otro cliente, ni el código proviene de ningún otro cliente, pero sí está influenciado e inspirado por Geth, Erigon y Akula. ()

Otro participante principal es Jump Trading y Jump Capital. El fundador de Monad proviene de Jump Trading y tiene una rica experiencia en operaciones de alta frecuencia; los inversores de Sei incluyen a Jump Capital, y Jump ha estado profundamente involucrado en el ecosistema de Solana, incluida la infraestructura y los proyectos. .

Dragonfly, uno de los primeros inversores en Monad, también ha estado prestando atención a pistas relacionadas: ha invertido en NEAR, que se centra en tecnología de fragmentación, así como en cadenas públicas como Aptos, Avalanche y Nervos.

Actualizar el algoritmo de consenso no es suficiente, finalmente es el turno de la capa de ejecución

En las últimas guerras de cadenas públicas, la capa de ejecución ha sido un lugar descuidado, casi solo se habla de la innovación de algoritmos de consenso, ya sea Solana, Avalanche o EOS. Aunque tienen muchas innovaciones en la capa de ejecución, la comunidad todavía recuerda el algoritmo de consenso que utilizaron, y toda la comunidad también piensa que el rendimiento de estas cadenas públicas de alto rendimiento proviene de la innovación del algoritmo de consenso.

Pero no es así: si se desea obtener una cadena pública de alto rendimiento, es necesario hacer coincidir el algoritmo de consenso y la capa de ejecución, lo que también está en consonancia con las deficiencias del barril de madera. Para aquellas cadenas públicas que se basan en EVM y solo mejoran el algoritmo de consenso, se necesitan nodos más fuertes para mejorar el rendimiento. Por ejemplo, BSC limita el gas que puede procesar un bloque al nivel de 2000 TPS, lo que requiere una configuración de la máquina varias veces la inversión de un nodo completo de Ethereum. En teoría, Polygon puede alcanzar 1000 TPS, pero por lo general es solo de decenas a cientos.

Los nodos de archivo BSC requieren al menos una CPU de 16 núcleos y 128 G de memoria, y los nodos Ethereum solo requieren al menos una CPU de 4 núcleos y 16 G de memoria.

El equipo del BSC es consciente desde hace tiempo de estos problemas, por lo que también está trabajando con NodeReal para desarrollar la tecnología Parallel EVM. Solo de esta manera podremos aumentar aún más la cantidad de transacciones que cada bloque puede procesar, permitir que se ejecuten más transacciones en paralelo y aumentar el límite superior de TPS.

Paralelismo: no solo actualizar de CPU de un solo núcleo a CPU de múltiples núcleos

En la mayoría de los sistemas blockchain, las transacciones se ejecutan completamente en secuencia. Puede considerarlo como una CPU de un solo núcleo. El siguiente cálculo solo se puede realizar después de que se complete el cálculo actual. Aunque este método es lento, sus ventajas son la simplicidad y la baja complejidad del sistema.

Pero si el futuro sistema blockchain necesita acceder a una escala de usuarios a nivel de Internet, una CPU de un solo núcleo definitivamente no será suficiente. Por lo tanto, actualizar a una máquina virtual paralelizada con CPU de múltiples núcleos puede procesar múltiples transacciones al mismo tiempo y aumentar el rendimiento. Sin embargo, existen muchos desafíos en la implementación de ingeniería. Por ejemplo, ¿qué debo hacer si dos transacciones procesadas al mismo tiempo escriben datos en el mismo contrato inteligente? Es necesario diseñar un nuevo mecanismo para resolver esta contradicción. Para la ejecución paralela de otros contratos inteligentes completamente no relacionados, el rendimiento se puede aumentar según la cantidad de subprocesos de procesamiento paralelo y la escala.

Además, Parallel EVM no solo mejora las capacidades paralelas, sino que también optimiza la eficiencia de ejecución de un solo subproceso. El director ejecutivo de Monad, Keone Hon, dijo: “…el verdadero cuello de botella (de EVM) es la lectura y escritura frecuente de estados al procesar cosas…”. También dijo que la ejecución paralela es solo una parte de la hoja de ruta y que la misión más amplia de Monad es centrarse en EVM y hacerlo lo más eficiente posible.

Por lo tanto, aunque Parallel EVM significa literalmente “paralelización”, en realidad es una optimización especial del rendimiento de cada componente de EVM, por lo que es probable que sus esfuerzos representen el límite de rendimiento según el estándar EVM.

EVM no es igual a Solidity

Escribir contratos inteligentes es una habilidad esencial para la mayoría de los desarrolladores de blockchain. Los ingenieros pueden utilizar Solidity u otros lenguajes de contratos inteligentes de alto nivel para escribir implementaciones lógicas correspondientes según las necesidades comerciales. Sin embargo, EVM en realidad no puede entender directamente la lógica de Solidity. Necesita pasar por alguna “traducción” y traducirla (compilarla) a un lenguaje de bajo nivel que la máquina pueda entender (código de operación / código de bytes) antes de poder entender. ser leído por la máquina virtual. Los desarrolladores de Solidity no necesitan comprender este proceso de traducción, porque ya existen herramientas maduras para implementarlo.

Después de todo, es “traducción”, por lo que también habrá algunos gastos generales (gastos generales adicionales). Los ingenieros con experiencia en codificación de bajo nivel pueden escribir la lógica del programa directamente utilizando códigos de operación en Solidity, lo que puede lograr el mayor rendimiento, lo que significa que los usuarios pueden ahorrar gas al realizar transacciones. Por ejemplo, el protocolo Seaport lanzado por Opensea utiliza ampliamente el ensamblaje en línea en contratos inteligentes para reducir los gastos de gas de los usuarios tanto como sea posible.

Por lo tanto, si finalmente se puede implementar Parallel EVM, no solo brindará capacidades de paralelización, sino que también optimizará el rendimiento de toda la pila EVM. Los desarrolladores de aplicaciones comunes no necesitan gastar mucha energía en la optimización solo para ahorrar un poco de gas, porque la máquina virtual subyacente es lo suficientemente potente como para suavizar estas diferencias.

El rendimiento de EVM varía y “estándar” no equivale a “práctica de ingeniería”

La “máquina virtual”, también llamada “capa de ejecución”, es el motor en el que finalmente se calculan y procesan los contratos inteligentes después de compilarlos en códigos de operación. El “código de bytes” definido por la máquina virtual Ethereum (EVM) ahora se ha convertido en un estándar de la industria. Ya sea una red de segunda capa basada en Ethereum u otras cadenas públicas independientes, están más dispuestas a ser directa y totalmente compatible con EVM. estándar antes de desarrollarlo, los autores pueden escribir contratos inteligentes una vez e implementarlos en múltiples redes, lo cual es extremadamente rentable.

Por lo tanto, siempre que sea totalmente compatible con el estándar “bytecode” de EVM, se puede llamar EVM, pero los métodos de implementación pueden variar ampliamente. Por ejemplo, el cliente Ethereum Geth utiliza el lenguaje Go para implementar el estándar EVM. Sin embargo, Ipsilon, el equipo de investigación de la capa de ejecución de la Fundación Ethereum, mantiene una implementación independiente de EVM desarrollada en C++. Otros clientes de Ethereum pueden llamar directamente a esta biblioteca para ejecutarla como EVM.

Por ejemplo, muchos productos producidos industrialmente tienen los estándares internacionales correspondientes. Por ejemplo, cuando un producto sale de la fábrica, el número de colonias debe ser menor que un cierto valor antes de que pueda venderse. Este es el “estándar”. Pero cómo cumplir con este estándar de fábrica, cada fábrica puede elegir entre docenas de métodos de esterilización diferentes, y algunas fábricas pueden encontrar formas más rentables de cumplir con este requisito: esto es “práctica”.

Dado que existe una implementación de evmone, también se pueden realizar otras implementaciones. Entonces, en este ejemplo de EVM, el estándar EVM define algunos métodos de operación básicos “código de bytes” (como admitir la aritmética más básica, como suma, resta, multiplicación, etc.). Cuando cada código de bytes tiene una determinada entrada, hay una salida definida. . Cuando se trata de cumplir este criterio, las implementaciones (y prácticas) varían ampliamente, con mucho espacio para la personalización y posibilidades de optimización de ingeniería.

Similitudes y diferencias de EVM paralelo

En la pista Parallel EVM, además de la Monad más popular, también están Sei, MegaETH, Polygon, Neon EVM, BSC, etc., y el cliente Reth de Paradigm también quiere implementar funciones de paralelización.

Desde una perspectiva de posicionamiento, Monad, Sei, Polygon y BSC son cadenas de bloques de Capa 1, mientras que MegaETH puede ser de Capa 2. Neon EVM se basa en la red Solana. Además, Reth es un cliente de código abierto y MegaETH seguirá desarrollándose parcialmente en base a proyectos de Reth.

Por supuesto, todavía hay competencia entre estos equipos y todos los detalles técnicos y documentos de ingeniería no se han revelado en su totalidad, por lo que habrá que esperar más comparaciones hasta que se divulguen gradualmente. Quizás esto sea nuevamente como una carrera armamentista, como BTC Layer 2, Restating y Ethereum Layer 2. Aunque existen diferencias sutiles entre las tecnologías (y el código abierto), lo que es más importante es cómo construir la singularidad del ecosistema.

Dificultades técnicas de Parallel EVM

Para transacciones ejecutadas secuencialmente, el cuello de botella es la CPU y el proceso de lectura y escritura del estado. Pero la ventaja es que este método es bastante simple, está libre de errores y todas las tareas se pueden completar paso a paso. Para las máquinas virtuales que se ejecutan en paralelo, puede haber conflictos de estado, por lo que esta parte del juicio debe agregarse antes o después de la ejecución.

Un ejemplo simple es que si la máquina virtual admite la ejecución paralela de cuatro subprocesos y cada subproceso puede procesar una transacción al mismo tiempo, si estas cuatro transacciones son todas transacciones con el mismo grupo de transacciones en Uniswap, no se pueden ejecutar en paralelo. Cálculo, porque cada transacción afectará el precio de transacción de este grupo de transacciones. Pero si estos cuatro hilos están trabajando en cuatro cosas que no tienen ninguna relación al mismo tiempo, entonces no hay problema.

Esto implicará la implementación de diseño e ingeniería de diferentes equipos, pero al menos lo que se debe garantizar es que después de la ejecución paralela, se necesite un módulo para detectar conflictos y volver a ejecutarlos si se encuentran conflictos. Por supuesto, si las transacciones que pueden entrar en conflicto se pueden predecir y detectar de antemano, también se puede aumentar la eficiencia paralela de toda la máquina virtual.

Además de las diferencias en la implementación de ingeniería de la máquina virtual Parallel EVM, cada equipo generalmente rediseñará y mejorará el rendimiento de lectura y escritura de la base de datos estatal y diseñará un algoritmo de consenso, como MonadDb y MonadBFT diseñados por Monad.

desafío

Para Parallel EVM, existen dos posibles desafíos: si Ethereum capturará el valor de ingeniería a largo plazo y la centralización de los nodos.

Dado que varios equipos aún se encuentran en las etapas de desarrollo y prueba de la tecnología Parallel EVM, aún no han optado por abrir el código fuente de todos los detalles de ingeniería, lo cual es uno de los fosos actuales. Sin embargo, después de ingresar a la red de prueba y a la red principal, estos documentos del proyecto se harán públicos y también podrán ser absorbidos por Ethereum u otras cadenas públicas. Por lo tanto, en ese momento, es necesario promover la construcción ecológica más rápido y construir más fosos ecológicos.

Sin embargo, este problema no es tan grave: por un lado, para los desarrolladores de Crypto, ahora hay más licencias de código abierto para elegir (como la licencia de Uniswap que puede hacer público el código pero no permite bifurcarlo en proyectos comerciales). Por otro lado, el posicionamiento de Monad es intrínsecamente diferente al de Ethereum. Incluso si Ethereum puede lograr la finalidad de un solo socket (SSF) en el futuro, la finalidad de las transacciones seguirá siendo de al menos 12 segundos, lo que está lejos de ser suficiente para escenarios de aplicaciones de mayor frecuencia.

Otro desafío común a todas las cadenas públicas de alto rendimiento es cómo implementar más nodos para cumplir con los requisitos básicos de los usuarios de no tener permisos ni confiar: la descentralización. Quizás se puedan cuantificar algunos indicadores, como “TPS dividido por los requisitos de hardware del nodo”, para que podamos controlar las variables y comparar qué cadena pública/cliente tiene un TPS más alto en función de los requisitos de hardware específicos. Después de todo, cuanto menores sean los requisitos de hardware de un nodo, mayor será el número de nodos posibles.

A continuación, continuaremos rastreando el progreso de cada proyecto Parallel EVM y discutiremos sus tecnologías y diferencias en detalle.