Optimización de paralelización EVM: la clave para superar el cuello de botella del rendimiento

Como es bien sabido, EVM es uno de los componentes centrales más importantes de Ethereum, posicionado como "motor de ejecución" y "entorno de ejecución de contratos inteligentes". Dado que la cadena pública es una red abierta que contiene una gran cantidad de nodos, las diferencias en los parámetros de hardware de los diferentes nodos son muy grandes. Para que los contratos inteligentes obtengan los mismos resultados en múltiples nodos y cumplan con el requisito de "consistencia", la tecnología de máquinas virtuales puede construir el mismo entorno en diferentes dispositivos.

EVM puede ejecutar contratos inteligentes de la misma manera en varios sistemas operativos y dispositivos, esta compatibilidad multiplataforma asegura que cada nodo obtenga resultados consistentes después de ejecutar el contrato. Esto es similar al principio de la máquina virtual de Java (JVM).

Los contratos inteligentes que vemos en el explorador de bloques se compilan primero en código de bytes EVM y luego se almacenan en la cadena. Al ejecutar un contrato, EVM lee estos códigos de bytes en orden, y cada instrucción tiene un costo de Gas correspondiente. EVM rastrea el consumo de Gas durante la ejecución de cada instrucción, y la cantidad consumida depende de la complejidad de la operación.

Como el motor de ejecución central de Ethereum, EVM procesa las transacciones de manera secuencial, todas las transacciones se ponen en cola en una única fila y se ejecutan en un orden determinado. La razón por la que no se utiliza un enfoque de paralelización es que la blockchain necesita cumplir estrictamente con la consistencia, un lote de transacciones debe ser procesado en el mismo orden en todos los nodos. Si se paraleliza el procesamiento de transacciones, es difícil predecir con precisión el orden de las transacciones, a menos que se introduzcan algoritmos de programación complejos.

El equipo fundador de Ethereum, debido a la presión del tiempo, optó en 2014-2015 por un enfoque de ejecución secuencial que era simple y fácil de mantener. Sin embargo, a medida que la tecnología blockchain ha evolucionado y la base de usuarios se ha expandido, las demandas sobre el TPS y el rendimiento han aumentado considerablemente. Con la madurez de la tecnología Rollup, los cuellos de botella de rendimiento causados por la ejecución secuencial de EVM se han vuelto evidentes en la red de segunda capa de Ethereum.

El Sequencer, como componente clave de Layer2, asume todas las tareas de cálculo en forma de un solo servidor. Si la eficiencia de los módulos externos que trabajan con el Sequencer es lo suficientemente alta, el cuello de botella final dependerá de la eficiencia del propio Sequencer, en ese momento la ejecución en serie se convertirá en un gran obstáculo.

Un equipo ha optimizado al máximo la capa DA y el módulo de lectura y escritura de datos, lo que permite al Secuenciador ejecutar más de 2000 transferencias ERC-20 por segundo. Esta cifra parece muy alta, pero si las transacciones que se procesan son mucho más complejas que las transferencias ERC-20, el valor de TPS disminuirá significativamente. Por lo tanto, la paralelización del procesamiento de transacciones se convertirá en una tendencia inevitable en el futuro.

A continuación, exploraremos en profundidad las limitaciones del EVM tradicional y las ventajas del EVM paralelo.

Dos componentes clave en la ejecución de transacciones de Ethereum

En el nivel del módulo de código, además de EVM, otro componente central relacionado con la ejecución de transacciones en go-ethereum es stateDB, que se utiliza para gestionar el estado de las cuentas y el almacenamiento de datos en Ethereum. Ethereum utiliza una estructura de árbol llamada Merkle Patricia Trie como índice de base de datos. Cada vez que se ejecuta una transacción, EVM cambia ciertos datos en stateDB, y estos cambios eventualmente se reflejarán en el árbol de estado global.

stateDB es responsable de mantener el estado de todas las cuentas de Ethereum, incluyendo cuentas EOA y cuentas de contrato. Los datos almacenados incluyen el saldo de la cuenta, el código del contrato inteligente, entre otros. Durante el proceso de ejecución de la transacción, stateDB leerá y escribirá los datos de las cuentas correspondientes. Al finalizar la ejecución de la transacción, stateDB necesita enviar el nuevo estado a la base de datos subyacente para su procesamiento de persistencia.

En general, EVM es responsable de interpretar y ejecutar las instrucciones de los contratos inteligentes, cambiando el estado en la blockchain según los resultados de los cálculos, mientras que stateDB actúa como un almacenamiento de estado global, gestionando todos los cambios de estado de cuentas y contratos. Ambos colaboran para construir el entorno de ejecución de transacciones de Ethereum.

El proceso específico de ejecución secuencial

Las transacciones de Ethereum se dividen en dos categorías: transferencias EOA y transacciones de contratos. Las transferencias EOA son el tipo de transacción más simple, es decir, transferencias de ETH entre cuentas normales, que no implican llamadas a contratos, tienen una velocidad de procesamiento muy rápida y una tarifa de gas extremadamente baja.

El comercio de contratos implica la llamada y ejecución de contratos inteligentes. Al procesar transacciones de contratos, la EVM necesita interpretar y ejecutar instrucción por instrucción el código de bytes dentro del contrato inteligente. Cuanto más compleja sea la lógica del contrato, más instrucciones estarán involucradas y más recursos se consumirán.

Por ejemplo, el tiempo de procesamiento de las transferencias ERC-20 es aproximadamente el doble que el de las transferencias EOA, y los contratos inteligentes más complejos (, como las operaciones de intercambio en algún DEX, ) tardan aún más, posiblemente siendo diez veces más lentos que las transferencias EOA. Esto se debe a que los protocolos DeFi necesitan manejar lógicas complejas como pools de liquidez, cálculos de precios y intercambios de tokens durante las transacciones, lo que requiere una gran cantidad de cálculos.

En el modo de ejecución en serie, el proceso de manejo de transacciones entre EVM y stateDB es el siguiente:

En el diseño de Ethereum, las transacciones dentro de un bloque se procesan secuencialmente, y cada transacción tiene una instancia independiente que ejecuta operaciones específicas. Aunque cada transacción utiliza diferentes instancias de EVM, todas las transacciones comparten la misma base de datos de estado stateDB.

Durante el proceso de ejecución de la transacción, EVM necesita interactuar constantemente con stateDB, leer los datos relevantes de él y escribir los datos modificados de vuelta a stateDB.

Desde el punto de vista del código, el flujo general de ejecución de transacciones mediante la colaboración entre EVM y stateDB es el siguiente:

1. La llamada a la función processBlock() procesa las transacciones en un bloque mediante la función Process().

2. El proceso () define un bucle for, las transacciones se ejecutan una por una.

3. Una vez que se hayan procesado todas las transacciones, la función processBlock() llama a la función writeBlockWithState(), y luego llama a la función statedb.Commit() para enviar los resultados de los cambios de estado.

Cuando se han ejecutado todas las transacciones en un bloque, los datos en stateDB se envían al árbol de estado global y se genera una nueva raíz de estado. La raíz de estado es un parámetro importante en cada bloque, que registra el "resultado comprimido" del nuevo estado global después de la ejecución del bloque.

El modo de ejecución en serie de EVM presenta un claro cuello de botella: las transacciones deben ejecutarse en orden, y si hay una transacción de contrato inteligente que toma mucho tiempo, las demás transacciones solo pueden esperar, lo que impide aprovechar plenamente los recursos de hardware como la CPU, limitando así la eficiencia.

Plan de optimización de paralelismo multihilo para EVM

Al comparar la ejecución en serie con la ejecución en paralelo, la primera es como un banco con un solo mostrador, mientras que el EVM en paralelo es como un banco con múltiples mostradores. En el modo paralelo, se pueden abrir múltiples hilos para procesar varias transacciones simultáneamente, lo que puede aumentar la eficiencia varias veces, pero el desafío que se enfrenta es el problema de conflictos de estado.

Si varias transacciones declaran que desean modificar los datos de una cuenta, se producirá un conflicto al procesarlas simultáneamente. Por ejemplo, si un NFT solo puede acuñarse una vez, y tanto la transacción 1 como la transacción 2 desean acuñar ese NFT, si se satisfacen ambas solicitudes, claramente habrá un error. En la práctica, los conflictos de estado ocurren con mayor frecuencia, por lo que la paralelización del procesamiento de transacciones debe tener medidas para abordar los conflictos de estado.

Principios de optimización paralela de EVM en un proyecto

Un proyecto ZKRollup tiene la idea de optimización paralela para EVM al asignar una transacción a cada hilo y proporcionar una base de datos de estado temporal en cada hilo, llamada pending-stateDB. Los detalles específicos son los siguientes:

1. Ejecución de transacciones en paralelo con múltiples hilos: Configura múltiples hilos para manejar diferentes transacciones simultáneamente, sin interferencias entre hilos, lo que puede aumentar varias veces la velocidad de procesamiento de transacciones.

2. Asignar una base de datos de estado temporal para cada hilo: cada hilo recibe una base de datos de estado temporal independiente (pending-stateDB). Al ejecutar transacciones, el hilo no modifica directamente el stateDB global, sino que registra temporalmente los resultados de los cambios de estado en la pending-stateDB.

3. Sincronización de cambios de estado: una vez que se han ejecutado todas las transacciones dentro de un bloque, la EVM sincroniza secuencialmente los resultados de los cambios de estado registrados en cada pending-stateDB a la global stateDB. Si no hay conflictos de estado durante la ejecución de diferentes transacciones, se pueden combinar sin problemas los registros del pending-stateDB en la global stateDB.

El proyecto ha optimizado el manejo de las operaciones de lectura y escritura, asegurando que las transacciones puedan acceder correctamente a los datos de estado y evitar conflictos:

Operación de lectura: cuando una transacción necesita leer el estado, el EVM primero verifica el ReadSet del estado pendiente. Si el ReadSet contiene los datos necesarios, los lee directamente de la base de datos del estado pendiente (pending-stateDB). Si el ReadSet no tiene el par clave-valor correspondiente, lee los datos del estado histórico de la base de datos del estado global (stateDB) del bloque anterior.

Operaciones de escritura: todas las operaciones de escritura (, es decir, modificaciones de estado ), no se escriben directamente en el stateDB global, sino que primero se registran en el WriteSet del estado pendiente. Después de que se complete la ejecución de la transacción, se intenta fusionar el resultado del cambio de estado en el stateDB global a través de la detección de conflictos.

El problema clave en la ejecución paralela es el conflicto de estado, que es especialmente notable cuando múltiples transacciones intentan leer y escribir el mismo estado de cuenta. Para ello, se ha introducido un mecanismo de detección de conflictos:

Detección de conflictos: Durante la ejecución de transacciones, EVM monitorea el ReadSet y WriteSet de diferentes transacciones. Si se detecta que múltiples transacciones intentan leer y escribir el mismo elemento de estado, se considera que ha ocurrido un conflicto.

Manejo de conflictos: Cuando se detecta un conflicto, la transacción en conflicto se marca como necesaria para volver a ejecutarse.

Después de que se completen todas las ejecuciones de transacciones, los registros de cambios en múltiples pending-stateDB se combinarán en el stateDB global. Si la combinación es exitosa, el EVM enviará el estado final al árbol de estado global y generará una nueva raíz de estado.

La optimización de la ejecución paralela de múltiples hilos mejora significativamente el rendimiento, especialmente al procesar transacciones complejas de contratos inteligentes. La investigación muestra que, en cargas de trabajo de bajo conflicto, el TPS de las pruebas de referencia aumenta entre 3 y 5 veces en comparación con la ejecución secuencial tradicional. En cargas de trabajo de alto conflicto, teóricamente, si se emplean todas las técnicas de optimización, se podría alcanzar un aumento de hasta 60 veces.

Resumen

La solución de optimización de paralelismo multihilo EVM mencionada anteriormente, asigna una biblioteca de estado temporal a cada transacción y ejecuta las transacciones en paralelo en diferentes hilos, lo que mejora significativamente la capacidad de procesamiento de transacciones de EVM. Al optimizar las operaciones de lectura y escritura e introducir un mecanismo de detección de conflictos, la cadena pública EVM puede lograr una paralelización a gran escala de las transacciones, garantizando la consistencia del estado, lo que resuelve el cuello de botella de rendimiento que presenta el modo de ejecución serial tradicional. Esto establece una base importante para el desarrollo futuro de Ethereum Rollup.

Las direcciones futuras de investigación incluyen: optimizar aún más la eficiencia de almacenamiento para mejorar el rendimiento, soluciones de optimización para enfrentar situaciones de alta congestión, y cómo aprovechar la GPU para la optimización, entre otros temas.