Reenviar el Título Original: Análisis Técnico Artela: ¿Por qué está relacionado el “EVM Paralelo” con la batalla por la supervivencia del ecosistema del EVM de Ethereum?
La reciente inversión principal de Paradigm de $225 millones en la ronda de financiación de Monad ha causado conmoción en el mercado, encendiendo un aumento de interés en "EVM paralelo". Pero, ¿qué aborda exactamente "EVM paralelo"? ¿Cuáles son los cuellos de botella y los desafíos clave en el desarrollo de EVM paralelo? Creo que "EVM paralelo" representa la última defensa de la cadena EVM contra las cadenas de capa 1 de alto rendimiento, una batalla que determinará la supervivencia del ecosistema de Ethereum EVM. ¿Por qué? Vamos a profundizar en mi comprensión:
La capacidad de procesamiento de transacciones "serie" inherente de la máquina virtual EVM de Ethereum ha impuesto restricciones significativas de rendimiento tanto a las cadenas de capa 1 compatibles con EVM como a las cadenas de capa 2 compatibles con EVM. Esto se debe al hecho de que todas dependen fundamentalmente del mismo marco para procesar el estado y la finalidad de las transacciones.
Por el contrario, cadenas de capa 1 de alto rendimiento como Solana, Sui y Aptos poseen ventajas inherentes de procesamiento paralelo. En este contexto, las cadenas basadas en EVM deben abordar su falta inherente de capacidades paralelas para competir efectivamente con estas cadenas públicas de capa 1 de alto rendimiento. Vamos a explorar los diferentes enfoques para implementar EVM paralelo, utilizando el ejemplo de Artela Network, una estrella en ascenso en el espacio de EVM paralelo:
1) Representadas por cadenas como Monad, Artela y SEI, estas cadenas mejoran significativamente el TPS al tiempo que permiten capacidades de transacciones paralelas dentro de un entorno cuasi-EVM. Estas cadenas paralelas independientes de capa 1 de EVM poseen mecanismos de consenso y características técnicas únicas, pero aún mantienen el objetivo de compatibilidad y expansión dentro del ecosistema de EVM. Esencialmente, reconstruyen las cadenas de EVM "cambiando su línea de sangre" para servir mejor al ecosistema de EVM.
2) Ejemplificado por cadenas como Eclipse y MegaETH, estas cadenas aprovechan el consenso independiente y las capacidades de "pre-procesamiento" de transacciones de las cadenas de capa 2 para filtrar y procesar los estados de transacción antes de agruparlos en la red principal. También pueden seleccionar la capa de ejecución de cualquier otra cadena para finalizar los estados de transacción. Este enfoque básicamente abstrae EVM en un módulo de ejecución enchufable, lo que permite la selección de la mejor "capa de ejecución" según sea necesario, logrando así capacidades paralelas. Sin embargo, si bien estas soluciones pueden servir a EVM, operan fuera del marco de EVM.
3)Representados por cadenas como Polygon y BSC, estas cadenas han logrado un cierto grado de capacidad de procesamiento paralelo de EVM. Sin embargo, sus optimizaciones se limitan a la capa del algoritmo, sin profundizar en las capas de consenso y almacenamiento. En consecuencia, sus capacidades paralelas se asemejan más a una característica específica que a una solución integral a los desafíos de paralelización de EVM.
4)Ejemplificado por cadenas como Aptos, Sui y Fuel, estas cadenas no son estrictamente cadenas EVM. En cambio, capitalizan sus altas capacidades de ejecución de concurrencia inherentes y emplean técnicas de middleware o análisis de código para lograr compatibilidad con el entorno EVM. Esto es evidente en el caso de Starknet, una solución de capa 2 de Ethereum. La compatibilidad de Starknet con EVM requiere un conducto especial debido a su lenguaje Cario y características de abstracción de cuentas. Este desafío de compatibilidad es un problema común con las cadenas no EVM que intentan conectarse con cadenas EVM.
Las cuatro aproximaciones mencionadas anteriormente tienen cada una su propio énfasis. Por ejemplo, la Capa 2 con capacidades paralelas se centra en la flexibilidad de las combinaciones modulares de cadenas de “capa de ejecución”, mientras que las cadenas compatibles con EVM destacan las características personalizadas de funciones específicas. En cuanto a otras cadenas no EVM con características de compatibilidad con EVM, su objetivo es aprovechar más la liquidez de Ethereum. El objetivo real es consolidar a fondo el ecosistema de EVM, dejando solo una pista reforzada de capa 1 de EVM para mejorar las capacidades paralelas.
Entonces, ¿cuáles son los factores clave para fortalecer una cadena pública paralela de capa 1 EVM? ¿Cómo podemos reconstruir una cadena EVM y seguir sirviendo al ecosistema EVM? Hay dos puntos clave:
La capacidad de acceder a la lectura del disco de E/S del estado y la información de salida. Dado que la lectura y escritura de datos lleva tiempo, simplemente ordenar y programar transacciones no puede mejorar fundamentalmente las capacidades de procesamiento paralelo. También requiere la introducción de almacenamiento en caché, particionamiento de datos e incluso tecnologías de almacenamiento distribuido para equilibrar la velocidad de lectura y la posibilidad de conflictos de estado desde el proceso fundamental de almacenamiento y lectura del estado.
Teniendo una comunicación de red eficiente, sincronización de datos, optimización de algoritmos, refuerzo de la máquina virtual y diversas optimizaciones de componentes de la capa de mecanismo de consenso, como la separación de tareas de cálculo y E/S, que requieren una optimización y mejora integrales desde diversos aspectos, incluida la arquitectura de componentes de capa inferior y procesos colaborativos. Esto conduce en última instancia a la capacidad de ejecutar transacciones paralelas rápidamente, con un consumo de cálculo controlable y alta precisión.
En cuanto al proyecto específico de la cadena paralela de capa 1 EVM en sí misma, ¿qué innovaciones tecnológicas y optimizaciones de marco se necesitan para lograr el "EVM paralelo"?
Para lograr completamente la coordinación de recursos y las capacidades de optimización de “EVM paralelo” desde la arquitectura de capa inferior, Artela introduce la Computación Elástica y el Espacio de Bloque Elástico. ¿Cómo entenderlos? La computación elástica permite a la red asignar y ajustar dinámicamente los recursos de computación según la demanda y la carga, mientras que el espacio de bloque elástico ajusta dinámicamente el tamaño del bloque en función del número de transacciones y el tamaño de los datos en la red. Todo el principio de diseño elástico funciona de manera similar a las escaleras mecánicas en los centros comerciales que detectan automáticamente el flujo de peatones, lo que tiene mucho sentido.
Como se mencionó anteriormente, el rendimiento de la lectura del disco de estado I/O es crucial para EVM paralelo. Cadenas compatibles con EVM como Polygon y BSC logran mejoras de eficiencia de 2-4 veces a través del paralelismo algorítmico, pero esto solo es una optimización a nivel algorítmico. La capa de consenso y la capa de almacenamiento no han pasado por una optimización profunda. ¿Cómo sería una verdadera optimización profunda?
En respuesta a esto, Artela recurre a soluciones tecnológicas de base de datos, mejorando tanto la lectura como la escritura de estados. Para escribir estados, introduce la tecnología de registro previo a la escritura (WAL), que registra los cambios antes de escribirlos en el disco. Esta operación asíncrona evita la escritura inmediata en el disco cuando cambia el estado, reduciendo las operaciones de E/S de disco. Para la lectura de estados, adopta esencialmente operaciones asíncronas mediante estrategias de precarga para mejorar la eficiencia de lectura. Al predecir qué estados serán necesarios en función del historial de ejecución del contrato y precargarlos en la memoria, mejora la eficiencia de las solicitudes de E/S de disco.
En resumen, este es un algoritmo que intercambia tiempo de ejecución por espacio de memoria, mejorando fundamentalmente las capacidades de procesamiento paralelo de la máquina virtual EVM y optimizando el problema de conflicto de estados desde cero.
Además, Artela introduce las capacidades de programación modular de Aspect para gestionar mejor la complejidad y mejorar la eficiencia del desarrollo. Al introducir el análisis de código WASM para mejorar la flexibilidad de programación y proporcionar permisos de acceso a API de bajo nivel, logra un aislamiento seguro de la capa de ejecución. Esto permite a los desarrolladores desarrollar, depurar e implementar de manera eficiente contratos inteligentes dentro del entorno de Artela, activando las capacidades de personalización y extensión de la comunidad de desarrolladores. En particular, se alentará a los desarrolladores a optimizar su código de contrato inteligente para el paralelismo, ya que reducir la probabilidad de conflictos de estado es crucial para la lógica de invocación y el algoritmo de cada contrato inteligente.
Eso es todo.
No es difícil para todos ver que el concepto de "Parallel EVM" esencialmente optimiza el proceso de ejecución del estado de transacción.@monad_xyzafirma poder lograr 10,000 transacciones por segundo, y su núcleo técnico no es más que lograr el procesamiento paralelo de transacciones a gran escala a través de bases de datos especializadas, amigabilidad para desarrolladores, consenso de ejecución diferida y tecnología de canal superscalar, etc. Esto no es muy diferente de la computación elástica y las operaciones asíncronas de E/S de Artela.
Lo que realmente quiero expresar es que este tipo de cadena EVM paralela de alto rendimiento es en realidad el resultado de integrar productos y capacidades técnicas de web2. De hecho, adopta la esencia de "manejo técnico" bajo alta carga de vez en cuando en el mercado de aplicaciones maduras de web2.
Si se observa el futuro lejano de la adopción masiva, “Parallel EVM” es de hecho la infraestructura básica para que el ecosistema EVM se enfrente a un mercado más amplio de web2, y es razonable que el mercado de capitales esté tan alcista.
Este artículo se reproduce de [Ver en la cadena], el derecho de autor pertenece al autor original [Hao Tian], si tiene alguna objeción a la reimpresión, por favor contacte al Gate Learnel equipo, y el equipo lo manejará tan pronto como sea posible de acuerdo con los procedimientos relevantes.
Descargo de responsabilidad: Las opiniones expresadas en este artículo representan únicamente las opiniones personales del autor y no constituyen ningún consejo de inversión.
Otras versiones del artículo en otros idiomas son traducidas por el equipo de Gate Learn y no se mencionan en Gate.io, el artículo traducido no puede ser reproducido, distribuido o plagiado.
Поділіться
Контент
Reenviar el Título Original: Análisis Técnico Artela: ¿Por qué está relacionado el “EVM Paralelo” con la batalla por la supervivencia del ecosistema del EVM de Ethereum?
La reciente inversión principal de Paradigm de $225 millones en la ronda de financiación de Monad ha causado conmoción en el mercado, encendiendo un aumento de interés en "EVM paralelo". Pero, ¿qué aborda exactamente "EVM paralelo"? ¿Cuáles son los cuellos de botella y los desafíos clave en el desarrollo de EVM paralelo? Creo que "EVM paralelo" representa la última defensa de la cadena EVM contra las cadenas de capa 1 de alto rendimiento, una batalla que determinará la supervivencia del ecosistema de Ethereum EVM. ¿Por qué? Vamos a profundizar en mi comprensión:
La capacidad de procesamiento de transacciones "serie" inherente de la máquina virtual EVM de Ethereum ha impuesto restricciones significativas de rendimiento tanto a las cadenas de capa 1 compatibles con EVM como a las cadenas de capa 2 compatibles con EVM. Esto se debe al hecho de que todas dependen fundamentalmente del mismo marco para procesar el estado y la finalidad de las transacciones.
Por el contrario, cadenas de capa 1 de alto rendimiento como Solana, Sui y Aptos poseen ventajas inherentes de procesamiento paralelo. En este contexto, las cadenas basadas en EVM deben abordar su falta inherente de capacidades paralelas para competir efectivamente con estas cadenas públicas de capa 1 de alto rendimiento. Vamos a explorar los diferentes enfoques para implementar EVM paralelo, utilizando el ejemplo de Artela Network, una estrella en ascenso en el espacio de EVM paralelo:
1) Representadas por cadenas como Monad, Artela y SEI, estas cadenas mejoran significativamente el TPS al tiempo que permiten capacidades de transacciones paralelas dentro de un entorno cuasi-EVM. Estas cadenas paralelas independientes de capa 1 de EVM poseen mecanismos de consenso y características técnicas únicas, pero aún mantienen el objetivo de compatibilidad y expansión dentro del ecosistema de EVM. Esencialmente, reconstruyen las cadenas de EVM "cambiando su línea de sangre" para servir mejor al ecosistema de EVM.
2) Ejemplificado por cadenas como Eclipse y MegaETH, estas cadenas aprovechan el consenso independiente y las capacidades de "pre-procesamiento" de transacciones de las cadenas de capa 2 para filtrar y procesar los estados de transacción antes de agruparlos en la red principal. También pueden seleccionar la capa de ejecución de cualquier otra cadena para finalizar los estados de transacción. Este enfoque básicamente abstrae EVM en un módulo de ejecución enchufable, lo que permite la selección de la mejor "capa de ejecución" según sea necesario, logrando así capacidades paralelas. Sin embargo, si bien estas soluciones pueden servir a EVM, operan fuera del marco de EVM.
3)Representados por cadenas como Polygon y BSC, estas cadenas han logrado un cierto grado de capacidad de procesamiento paralelo de EVM. Sin embargo, sus optimizaciones se limitan a la capa del algoritmo, sin profundizar en las capas de consenso y almacenamiento. En consecuencia, sus capacidades paralelas se asemejan más a una característica específica que a una solución integral a los desafíos de paralelización de EVM.
4)Ejemplificado por cadenas como Aptos, Sui y Fuel, estas cadenas no son estrictamente cadenas EVM. En cambio, capitalizan sus altas capacidades de ejecución de concurrencia inherentes y emplean técnicas de middleware o análisis de código para lograr compatibilidad con el entorno EVM. Esto es evidente en el caso de Starknet, una solución de capa 2 de Ethereum. La compatibilidad de Starknet con EVM requiere un conducto especial debido a su lenguaje Cario y características de abstracción de cuentas. Este desafío de compatibilidad es un problema común con las cadenas no EVM que intentan conectarse con cadenas EVM.
Las cuatro aproximaciones mencionadas anteriormente tienen cada una su propio énfasis. Por ejemplo, la Capa 2 con capacidades paralelas se centra en la flexibilidad de las combinaciones modulares de cadenas de “capa de ejecución”, mientras que las cadenas compatibles con EVM destacan las características personalizadas de funciones específicas. En cuanto a otras cadenas no EVM con características de compatibilidad con EVM, su objetivo es aprovechar más la liquidez de Ethereum. El objetivo real es consolidar a fondo el ecosistema de EVM, dejando solo una pista reforzada de capa 1 de EVM para mejorar las capacidades paralelas.
Entonces, ¿cuáles son los factores clave para fortalecer una cadena pública paralela de capa 1 EVM? ¿Cómo podemos reconstruir una cadena EVM y seguir sirviendo al ecosistema EVM? Hay dos puntos clave:
La capacidad de acceder a la lectura del disco de E/S del estado y la información de salida. Dado que la lectura y escritura de datos lleva tiempo, simplemente ordenar y programar transacciones no puede mejorar fundamentalmente las capacidades de procesamiento paralelo. También requiere la introducción de almacenamiento en caché, particionamiento de datos e incluso tecnologías de almacenamiento distribuido para equilibrar la velocidad de lectura y la posibilidad de conflictos de estado desde el proceso fundamental de almacenamiento y lectura del estado.
Teniendo una comunicación de red eficiente, sincronización de datos, optimización de algoritmos, refuerzo de la máquina virtual y diversas optimizaciones de componentes de la capa de mecanismo de consenso, como la separación de tareas de cálculo y E/S, que requieren una optimización y mejora integrales desde diversos aspectos, incluida la arquitectura de componentes de capa inferior y procesos colaborativos. Esto conduce en última instancia a la capacidad de ejecutar transacciones paralelas rápidamente, con un consumo de cálculo controlable y alta precisión.
En cuanto al proyecto específico de la cadena paralela de capa 1 EVM en sí misma, ¿qué innovaciones tecnológicas y optimizaciones de marco se necesitan para lograr el "EVM paralelo"?
Para lograr completamente la coordinación de recursos y las capacidades de optimización de “EVM paralelo” desde la arquitectura de capa inferior, Artela introduce la Computación Elástica y el Espacio de Bloque Elástico. ¿Cómo entenderlos? La computación elástica permite a la red asignar y ajustar dinámicamente los recursos de computación según la demanda y la carga, mientras que el espacio de bloque elástico ajusta dinámicamente el tamaño del bloque en función del número de transacciones y el tamaño de los datos en la red. Todo el principio de diseño elástico funciona de manera similar a las escaleras mecánicas en los centros comerciales que detectan automáticamente el flujo de peatones, lo que tiene mucho sentido.
Como se mencionó anteriormente, el rendimiento de la lectura del disco de estado I/O es crucial para EVM paralelo. Cadenas compatibles con EVM como Polygon y BSC logran mejoras de eficiencia de 2-4 veces a través del paralelismo algorítmico, pero esto solo es una optimización a nivel algorítmico. La capa de consenso y la capa de almacenamiento no han pasado por una optimización profunda. ¿Cómo sería una verdadera optimización profunda?
En respuesta a esto, Artela recurre a soluciones tecnológicas de base de datos, mejorando tanto la lectura como la escritura de estados. Para escribir estados, introduce la tecnología de registro previo a la escritura (WAL), que registra los cambios antes de escribirlos en el disco. Esta operación asíncrona evita la escritura inmediata en el disco cuando cambia el estado, reduciendo las operaciones de E/S de disco. Para la lectura de estados, adopta esencialmente operaciones asíncronas mediante estrategias de precarga para mejorar la eficiencia de lectura. Al predecir qué estados serán necesarios en función del historial de ejecución del contrato y precargarlos en la memoria, mejora la eficiencia de las solicitudes de E/S de disco.
En resumen, este es un algoritmo que intercambia tiempo de ejecución por espacio de memoria, mejorando fundamentalmente las capacidades de procesamiento paralelo de la máquina virtual EVM y optimizando el problema de conflicto de estados desde cero.
Además, Artela introduce las capacidades de programación modular de Aspect para gestionar mejor la complejidad y mejorar la eficiencia del desarrollo. Al introducir el análisis de código WASM para mejorar la flexibilidad de programación y proporcionar permisos de acceso a API de bajo nivel, logra un aislamiento seguro de la capa de ejecución. Esto permite a los desarrolladores desarrollar, depurar e implementar de manera eficiente contratos inteligentes dentro del entorno de Artela, activando las capacidades de personalización y extensión de la comunidad de desarrolladores. En particular, se alentará a los desarrolladores a optimizar su código de contrato inteligente para el paralelismo, ya que reducir la probabilidad de conflictos de estado es crucial para la lógica de invocación y el algoritmo de cada contrato inteligente.
Eso es todo.
No es difícil para todos ver que el concepto de "Parallel EVM" esencialmente optimiza el proceso de ejecución del estado de transacción.@monad_xyzafirma poder lograr 10,000 transacciones por segundo, y su núcleo técnico no es más que lograr el procesamiento paralelo de transacciones a gran escala a través de bases de datos especializadas, amigabilidad para desarrolladores, consenso de ejecución diferida y tecnología de canal superscalar, etc. Esto no es muy diferente de la computación elástica y las operaciones asíncronas de E/S de Artela.
Lo que realmente quiero expresar es que este tipo de cadena EVM paralela de alto rendimiento es en realidad el resultado de integrar productos y capacidades técnicas de web2. De hecho, adopta la esencia de "manejo técnico" bajo alta carga de vez en cuando en el mercado de aplicaciones maduras de web2.
Si se observa el futuro lejano de la adopción masiva, “Parallel EVM” es de hecho la infraestructura básica para que el ecosistema EVM se enfrente a un mercado más amplio de web2, y es razonable que el mercado de capitales esté tan alcista.
Este artículo se reproduce de [Ver en la cadena], el derecho de autor pertenece al autor original [Hao Tian], si tiene alguna objeción a la reimpresión, por favor contacte al Gate Learnel equipo, y el equipo lo manejará tan pronto como sea posible de acuerdo con los procedimientos relevantes.
Descargo de responsabilidad: Las opiniones expresadas en este artículo representan únicamente las opiniones personales del autor y no constituyen ningún consejo de inversión.
Otras versiones del artículo en otros idiomas son traducidas por el equipo de Gate Learn y no se mencionan en Gate.io, el artículo traducido no puede ser reproducido, distribuido o plagiado.