EVM Paralelización: La clave para resolver el cuello de botella de rendimiento de Ethereum

EVM, como el motor de ejecución de Ethereum y el entorno de ejecución de contratos inteligentes, es uno de sus componentes más centrales. Para garantizar que los contratos inteligentes produzcan los mismos resultados en diferentes nodos y cumplir con los requisitos de consistencia, la tecnología de máquina virtual se convierte en la mejor opción. EVM puede ejecutar contratos inteligentes de la misma manera en diferentes sistemas operativos y dispositivos, asegurando la compatibilidad multiplataforma.

Los contratos inteligentes se compilan en código de bytes EVM antes de ser subidos a la cadena. Al ejecutar el 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 motor de ejecución central, EVM maneja las transacciones de manera secuencial, con todas las transacciones en una única cola y ejecutándose en un orden determinado. Este diseño es simple y fácil de mantener, pero a medida que la base de usuarios crece y la tecnología avanza, sus cuellos de botella de rendimiento se hacen cada vez más evidentes, especialmente en Layer2.

Para el componente clave de Layer2, el Sequencer, si la eficiencia de los módulos de soporte es lo suficientemente alta, el cuello de botella final dependerá de la eficiencia del Sequencer mismo. Un equipo ha logrado optimizar de manera extrema, permitiendo que el Sequencer ejecute más de 2000 transferencias ERC-20 por segundo. Sin embargo, para transacciones más complejas, el TPS inevitablemente disminuirá drásticamente. Por lo tanto, la paralelización del procesamiento de transacciones se convierte en una tendencia inevitable para el futuro.

Componente central de la ejecución de transacciones de Ethereum

Además de EVM, otro componente central estrechamente relacionado con la ejecución de transacciones es stateDB, que se utiliza para gestionar el estado de las cuentas y el almacenamiento de datos de Ethereum. Ethereum utiliza una estructura de árbol Merkle Patricia Trie como índice de base de datos. Cada vez que se ejecuta una transacción, se modifican ciertos datos en stateDB, y estos cambios se reflejan finalmente 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, almacenando el saldo de la cuenta, el código del contrato inteligente y otros datos. Durante el proceso de ejecución de la transacción, stateDB lee y escribe los datos de las cuentas correspondientes. Al finalizar la ejecución de la transacción, stateDB envía el nuevo estado a la base de datos subyacente para su persistencia.

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

Limitaciones de la ejecución en serie

Las transacciones de Ethereum se dividen en dos categorías: transferencias EOA y transacciones de contrato. Las transferencias EOA son el tipo de transacción más simple, con una velocidad de procesamiento rápida y tarifas de gas bajas. Por otro lado, las transacciones de contrato implican la invocación y ejecución de contratos inteligentes, donde la EVM necesita interpretar y ejecutar línea por línea las instrucciones de bytes del contrato, lo que conlleva una mayor complejidad y consumo de recursos.

En el modo de ejecución en serie, las transacciones dentro de un bloque se procesan una a una en orden secuencial. Cada transacción tiene una instancia de EVM independiente, pero todas las transacciones comparten la misma stateDB. Durante el proceso de ejecución, el EVM necesita interactuar constantemente con la stateDB, leyendo datos y escribiendo los resultados modificados.

El cuello de botella de este modo de ejecución en serie es evidente: las transacciones deben ejecutarse en cola, y si hay una transacción de contrato inteligente que tarda mucho tiempo, las otras transacciones solo pueden esperar, lo que impide aprovechar al máximo los recursos de hardware y limita considerablemente la eficiencia.

Optimización paralela de múltiples hilos de EVM

Para superar las limitaciones de la ejecución secuencial, la industria ha propuesto un plan de optimización de múltiples hilos en el EVM. Este plan es similar a un banco donde múltiples ventanillas sirven al mismo tiempo, pudiendo procesar varias transacciones simultáneamente, lo que mejora significativamente la eficiencia. Sin embargo, el principal desafío que enfrenta la ejecución paralela es el problema de conflictos de estado, que requiere medidas especiales para abordarlo.

La idea de optimización paralela de un proyecto para EVM es la siguiente:

1. Configura varios hilos para procesar diferentes transacciones al mismo tiempo, sin interferencias entre hilos.

2. Asignar una base de datos de estado temporal independiente (pending-stateDB) para cada hilo. Cuando los hilos ejecutan transacciones, los cambios de estado se registran temporalmente en pending-stateDB, en lugar de modificar directamente el stateDB global.

3. Después de que se hayan ejecutado todas las transacciones dentro del bloque, los cambios de estado en cada pending-stateDB se sincronizan secuencialmente con el stateDB global. Si no hay conflictos, se pueden fusionar los registros sin problemas.

Esta solución optimiza las operaciones de lectura y escritura:

• Operación de lectura: primero verifica el ReadSet en estado pendiente; si se necesitan datos, léalos directamente; de lo contrario, lee el estado histórico de la base de datos de estado global del bloque anterior.

• Operación de escritura: todas las modificaciones se registran primero en el WriteSet del estado pendiente y se intenta fusionar en la stateDB global una vez que se completa la ejecución de la transacción.

Para resolver el problema de conflictos de estado, se introdujo un mecanismo de detección de conflictos:

• Monitorear el ReadSet y WriteSet de diferentes transacciones, considerando como conflicto cuando múltiples transacciones intentan leer y escribir el mismo elemento de estado.
• Marcar las transacciones en conflicto como necesarias para volver a ejecutar.

Una vez que se completan todas las ejecuciones de transacciones, los registros de cambios en múltiples pending-stateDB se combinan en el stateDB global. Después de la fusión exitosa, el estado final se envía al árbol de estado global, generando una nueva raíz de estado.

Las investigaciones muestran que, en cargas de trabajo de bajo conflicto, el TPS ejecutado en paralelo mejora entre 3 y 5 veces en comparación con la ejecución tradicional en serie. En cargas de trabajo de alto conflicto, teóricamente, después de una optimización adecuada, podría alcanzar incluso una mejora de 60 veces.

Resumen

La solución de optimización de paralelismo multihilo de EVM asigna una biblioteca de estado temporal a cada transacción y ejecuta las transacciones en paralelo en diferentes hilos, mejorando significativamente la capacidad de procesamiento de transacciones. Al optimizar las operaciones de lectura y escritura e introducir un mecanismo de detección de conflictos, se ha logrado una paralelización masiva de las transacciones, asegurando la consistencia del estado y resolviendo el cuello de botella de rendimiento del modo de ejecución serial tradicional. Esto sienta una base importante para el desarrollo futuro de Rollup de Ethereum.

En el futuro, también se podrá explorar cómo optimizar la eficiencia de almacenamiento, enfrentar situaciones de alta contención y realizar optimizaciones utilizando GPU, entre otras direcciones, para mejorar aún más el rendimiento de EVM.