Optimización de la paralelización EVM: explorando el camino hacia la mejora del rendimiento a través de Reddio
Como todos saben, EVM es uno de los componentes más importantes de Ethereum, desempeñando un papel crucial como "motor de ejecución" y "entorno de ejecución de contratos inteligentes". En una red abierta como la blockchain, compuesta por miles de nodos, la configuración de hardware de diferentes nodos puede variar significativamente. Para garantizar que los contratos inteligentes obtengan resultados de ejecución consistentes en todos los nodos, la tecnología de máquinas virtuales se convierte en la solución ideal.
EVM puede ejecutar contratos inteligentes de la misma manera en diferentes sistemas operativos y dispositivos, esta compatibilidad multiplataforma garantiza que cada nodo obtenga resultados consistentes después de ejecutar el contrato. Esto es similar al principio de la máquina virtual Java (JVM).
Los contratos inteligentes que vemos en el explorador de bloques se compilan primero en bytecode EVM y luego se almacenan en la cadena. Al ejecutar un contrato, EVM lee secuencialmente este bytecode, 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, donde todas las transacciones se colocan en una única cola y se ejecutan en un orden determinado. La razón por la que no se utiliza un enfoque de paralelización es porque la blockchain necesita garantizar estrictamente la consistencia; el mismo lote de transacciones debe ser procesado en el mismo orden en todos los nodos. Si se paraleliza el procesamiento de transacciones, sería difícil predecir con precisión el orden de las transacciones, a menos que se introduzcan algoritmos de programación complejos.
En 2014-2015, el equipo fundador de Ethereum, debido a la urgencia de tiempo, eligió un enfoque de ejecución secuencial que era simple en diseño y fácil de mantener. Sin embargo, con la iteración de la tecnología blockchain y la expansión de la base de usuarios, la demanda de TPS y capacidad de procesamiento ha ido en aumento. Con la aparición y maduración de la tecnología Rollup, los cuellos de botella de rendimiento causados por la ejecución secuencial de EVM se han hecho evidentes en la red de segunda capa de Ethereum.
El secuenciador, como componente clave de Layer2, asume todas las tareas de cálculo en forma de un único servidor. Si los módulos externos que trabajan con el secuenciador son lo suficientemente eficientes, el cuello de botella final dependerá de la eficiencia del secuenciador en sí, en este 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, permitiendo que el Secuenciador ejecute hasta más de 2000 transferencias ERC-20 por segundo. Este número parece muy alto, pero si las transacciones a procesar son mucho más complejas que las transferencias ERC-20, el valor de TPS sin duda disminuirá significativamente. Por lo tanto, la paralelización del procesamiento de transacciones será una tendencia inevitable en el futuro.
Dos componentes clave en la ejecución de transacciones de Ethereum
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, y cada ejecución de transacción en EVM modifica ciertos datos almacenados en stateDB; estos cambios se reflejarán finalmente en el árbol de estado global.
stateDB se encarga de mantener el estado de todas las cuentas de Ethereum, incluyendo cuentas EOA y cuentas de contrato, y 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 realizará operaciones de lectura y escritura sobre 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.
Proceso específico de ejecución en serie
Los tipos de transacciones en Ethereum se dividen en transferencias EOA y transacciones de contrato. Las transferencias EOA son el tipo de transacción más simple, es decir, transferencias de ETH entre cuentas normales, que no implican la llamada a contratos, son muy rápidas en su procesamiento y la tarifa de gas cobrada es muy baja.
El comercio de contratos implica la invocación y ejecución de contratos inteligentes. Al procesar transacciones de contratos, la EVM necesita interpretar y ejecutar una por una las instrucciones de bytecode en el contrato inteligente; cuanto más compleja sea la lógica del contrato, más instrucciones se involucrarán y más recursos se consumirán.
Por ejemplo, el tiempo de procesamiento de una transferencia ERC-20 es aproximadamente el doble que el de una transferencia EOA, mientras que las operaciones de contratos inteligentes más complejas, como las transacciones en un DEX, pueden tardar hasta diez veces más que una transferencia EOA. Esto se debe a que los protocolos DeFi necesitan manejar la lógica compleja de los pools de liquidez, el cálculo de precios, el intercambio de tokens, entre otros, lo que requiere una gran cantidad de cálculos.
En el modo de ejecución en serie, el proceso en el que el EVM y el stateDB colaboran para procesar las transacciones es el siguiente:
En el diseño de Ethereum, las transacciones dentro de un bloque se procesan una a una en orden secuencial, y cada transacción tiene una instancia independiente que ejecuta operaciones concretas. Aunque cada transacción utiliza una instancia diferente de EVM, todas las transacciones comparten la misma base de datos de estado, stateDB.
Durante el proceso de ejecución de la transacción, el EVM necesita interactuar constantemente con la stateDB, leer los datos relevantes de la stateDB y escribir los datos modificados de nuevo en la stateDB.
Cuando se completan 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 cuello de botella del modo de ejecución en serie de EVM es evidente: las transacciones deben ejecutarse en orden, y si hay una transacción de contrato inteligente que tarda mucho tiempo, las otras transacciones solo pueden esperar hasta que se complete su procesamiento, lo que claramente no puede aprovechar plenamente los recursos de hardware como la CPU, y la eficiencia se ve bastante limitada.
Solución de optimización de paralelismo multihilo de EVM
La ejecución en serie y la ejecución en paralelo se pueden comparar con un banco que tiene solo un mostrador y un banco que tiene múltiples mostradores. En el modo paralelo, se pueden abrir múltiples hilos para procesar varias transacciones al mismo tiempo, lo que puede aumentar la eficiencia varias veces, pero el problema complicado es el conflicto de estado.
Si varias transacciones declararan modificar los datos de una cuenta, se produciría un conflicto si se procesan simultáneamente. Por ejemplo, si un NFT solo puede ser acuñado una vez, y tanto la transacción 1 como la transacción 2 declaran acuñar ese NFT, si ambas solicitudes se cumplen, evidentemente habrá un error. En la práctica, los conflictos de estado son mucho más frecuentes, por lo que el procesamiento paralelo de transacciones debe contar con medidas para abordar los conflictos de estado.
Principios de optimización paralela de Reddio para EVM
Un proyecto de ZKRollup tiene la idea de optimización paralela para EVM asignando una transacción a cada hilo y proporcionando una base de datos de estado temporal en cada hilo, llamada pending-stateDB. Los detalles específicos son los siguientes:
Ejecución de transacciones en paralelo con múltiples hilos: configurar varios hilos para procesar diferentes transacciones simultáneamente, sin interferencia entre ellos. Esto puede aumentar varias veces la velocidad de procesamiento de transacciones.
Asignar una base de datos de estado temporal para cada hilo: asignar una base de datos de estado temporal independiente (pending-stateDB) para cada hilo. Cada hilo, al ejecutar transacciones, no modifica directamente el stateDB global, sino que registra temporalmente los resultados de los cambios de estado en la pending-stateDB.
Sincronización de cambios de estado: Una vez que se han completado todas las transacciones dentro de un bloque, la EVM sincronizará secuencialmente los resultados de los cambios de estado registrados en cada pending-stateDB en el stateDB global. Si no hay conflictos de estado durante la ejecución de diferentes transacciones, se pueden fusionar sin problemas los registros del pending-stateDB en el stateDB global.
El proyecto ha optimizado la forma en que se manejan las operaciones de lectura y escritura para garantizar 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 requeridos, se leen directamente del pending-stateDB. Si no se encuentra el par clave-valor correspondiente en el ReadSet, se leen los datos de estado histórico del global stateDB del bloque anterior.
Operaciones de escritura: Todas las operaciones de escritura (, es decir, las modificaciones al estado ), no se escriben directamente en la 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 los resultados de los cambios de estado en la stateDB global a través de la detección de conflictos.
La clave del problema de la ejecución paralela radica en los conflictos de estado; este problema es particularmente notable cuando múltiples transacciones intentan leer y escribir el estado de la misma cuenta. Para ello, se introduce un mecanismo de detección de conflictos:
Detección de conflictos: Durante el proceso de 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 marcará como necesaria para su reejecución.
Después de que se completen todas las transacciones, los registros de cambios en múltiples stateDB en estado pendiente se combinarán en el stateDB global. Si la combinación tiene éxito, el EVM enviará el estado final al árbol de estado global y generará una nueva raíz de estado.
La optimización de la paralelización multihilo tiene un impacto significativo en el rendimiento, especialmente al manejar transacciones complejas de contratos inteligentes. Las investigaciones muestran que, en un grupo de transacciones con baja carga de conflictos (, donde hay menos contradicciones o transacciones que ocupan los mismos recursos ), el TPS de las pruebas de referencia se incrementó aproximadamente entre 3 y 5 veces en comparación con la ejecución secuencial tradicional. En cargas de trabajo de alta conflictividad, teóricamente, si se aplican todas las medidas de optimización, se podría alcanzar incluso un aumento de hasta 60 veces.
Resumen
La solución de optimización de paralelismo multihilo de EVM del proyecto, asignando una biblioteca de estado temporal a cada transacción y ejecutando transacciones en paralelo en diferentes hilos, ha mejorado 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 masiva de transacciones, garantizando la consistencia del estado, resolviendo así el cuello de botella de rendimiento que presenta el modo de ejecución serial tradicional. Esto sienta una base importante para el futuro desarrollo de Rollup de Ethereum.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
20 me gusta
Recompensa
20
5
Compartir
Comentar
0/400
SocialFiQueen
· 08-05 12:02
Es comparable a Hongmeng.
Ver originalesResponder0
SerumSquirter
· 08-05 00:36
entra en reddio, rápido a trabajar
Ver originalesResponder0
SocialAnxietyStaker
· 08-03 20:27
¡Increíble el multihilo!
Ver originalesResponder0
GamefiEscapeArtist
· 08-03 20:25
Después de tanto tiempo, v1 todavía no se optimiza muy bien.
Ver originalesResponder0
AllInDaddy
· 08-03 20:00
¿Quién entiende a reddio? Es como el hermano Knife, subiendo a la orilla.
Optimización de múltiples hilos en EVM: desbloqueo del cuello de botella en el rendimiento de Rollup
Optimización de la paralelización EVM: explorando el camino hacia la mejora del rendimiento a través de Reddio
Como todos saben, EVM es uno de los componentes más importantes de Ethereum, desempeñando un papel crucial como "motor de ejecución" y "entorno de ejecución de contratos inteligentes". En una red abierta como la blockchain, compuesta por miles de nodos, la configuración de hardware de diferentes nodos puede variar significativamente. Para garantizar que los contratos inteligentes obtengan resultados de ejecución consistentes en todos los nodos, la tecnología de máquinas virtuales se convierte en la solución ideal.
EVM puede ejecutar contratos inteligentes de la misma manera en diferentes sistemas operativos y dispositivos, esta compatibilidad multiplataforma garantiza que cada nodo obtenga resultados consistentes después de ejecutar el contrato. Esto es similar al principio de la máquina virtual Java (JVM).
Los contratos inteligentes que vemos en el explorador de bloques se compilan primero en bytecode EVM y luego se almacenan en la cadena. Al ejecutar un contrato, EVM lee secuencialmente este bytecode, 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, donde todas las transacciones se colocan en una única cola y se ejecutan en un orden determinado. La razón por la que no se utiliza un enfoque de paralelización es porque la blockchain necesita garantizar estrictamente la consistencia; el mismo lote de transacciones debe ser procesado en el mismo orden en todos los nodos. Si se paraleliza el procesamiento de transacciones, sería difícil predecir con precisión el orden de las transacciones, a menos que se introduzcan algoritmos de programación complejos.
En 2014-2015, el equipo fundador de Ethereum, debido a la urgencia de tiempo, eligió un enfoque de ejecución secuencial que era simple en diseño y fácil de mantener. Sin embargo, con la iteración de la tecnología blockchain y la expansión de la base de usuarios, la demanda de TPS y capacidad de procesamiento ha ido en aumento. Con la aparición y maduración de la tecnología Rollup, los cuellos de botella de rendimiento causados por la ejecución secuencial de EVM se han hecho evidentes en la red de segunda capa de Ethereum.
El secuenciador, como componente clave de Layer2, asume todas las tareas de cálculo en forma de un único servidor. Si los módulos externos que trabajan con el secuenciador son lo suficientemente eficientes, el cuello de botella final dependerá de la eficiencia del secuenciador en sí, en este 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, permitiendo que el Secuenciador ejecute hasta más de 2000 transferencias ERC-20 por segundo. Este número parece muy alto, pero si las transacciones a procesar son mucho más complejas que las transferencias ERC-20, el valor de TPS sin duda disminuirá significativamente. Por lo tanto, la paralelización del procesamiento de transacciones será una tendencia inevitable en el futuro.
Dos componentes clave en la ejecución de transacciones de Ethereum
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, y cada ejecución de transacción en EVM modifica ciertos datos almacenados en stateDB; estos cambios se reflejarán finalmente en el árbol de estado global.
stateDB se encarga de mantener el estado de todas las cuentas de Ethereum, incluyendo cuentas EOA y cuentas de contrato, y 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 realizará operaciones de lectura y escritura sobre 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.
Proceso específico de ejecución en serie
Los tipos de transacciones en Ethereum se dividen en transferencias EOA y transacciones de contrato. Las transferencias EOA son el tipo de transacción más simple, es decir, transferencias de ETH entre cuentas normales, que no implican la llamada a contratos, son muy rápidas en su procesamiento y la tarifa de gas cobrada es muy baja.
El comercio de contratos implica la invocación y ejecución de contratos inteligentes. Al procesar transacciones de contratos, la EVM necesita interpretar y ejecutar una por una las instrucciones de bytecode en el contrato inteligente; cuanto más compleja sea la lógica del contrato, más instrucciones se involucrarán y más recursos se consumirán.
Por ejemplo, el tiempo de procesamiento de una transferencia ERC-20 es aproximadamente el doble que el de una transferencia EOA, mientras que las operaciones de contratos inteligentes más complejas, como las transacciones en un DEX, pueden tardar hasta diez veces más que una transferencia EOA. Esto se debe a que los protocolos DeFi necesitan manejar la lógica compleja de los pools de liquidez, el cálculo de precios, el intercambio de tokens, entre otros, lo que requiere una gran cantidad de cálculos.
En el modo de ejecución en serie, el proceso en el que el EVM y el stateDB colaboran para procesar las transacciones es el siguiente:
En el diseño de Ethereum, las transacciones dentro de un bloque se procesan una a una en orden secuencial, y cada transacción tiene una instancia independiente que ejecuta operaciones concretas. Aunque cada transacción utiliza una instancia diferente de EVM, todas las transacciones comparten la misma base de datos de estado, stateDB.
Durante el proceso de ejecución de la transacción, el EVM necesita interactuar constantemente con la stateDB, leer los datos relevantes de la stateDB y escribir los datos modificados de nuevo en la stateDB.
Cuando se completan 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 cuello de botella del modo de ejecución en serie de EVM es evidente: las transacciones deben ejecutarse en orden, y si hay una transacción de contrato inteligente que tarda mucho tiempo, las otras transacciones solo pueden esperar hasta que se complete su procesamiento, lo que claramente no puede aprovechar plenamente los recursos de hardware como la CPU, y la eficiencia se ve bastante limitada.
Solución de optimización de paralelismo multihilo de EVM
La ejecución en serie y la ejecución en paralelo se pueden comparar con un banco que tiene solo un mostrador y un banco que tiene múltiples mostradores. En el modo paralelo, se pueden abrir múltiples hilos para procesar varias transacciones al mismo tiempo, lo que puede aumentar la eficiencia varias veces, pero el problema complicado es el conflicto de estado.
Si varias transacciones declararan modificar los datos de una cuenta, se produciría un conflicto si se procesan simultáneamente. Por ejemplo, si un NFT solo puede ser acuñado una vez, y tanto la transacción 1 como la transacción 2 declaran acuñar ese NFT, si ambas solicitudes se cumplen, evidentemente habrá un error. En la práctica, los conflictos de estado son mucho más frecuentes, por lo que el procesamiento paralelo de transacciones debe contar con medidas para abordar los conflictos de estado.
Principios de optimización paralela de Reddio para EVM
Un proyecto de ZKRollup tiene la idea de optimización paralela para EVM asignando una transacción a cada hilo y proporcionando una base de datos de estado temporal en cada hilo, llamada pending-stateDB. Los detalles específicos son los siguientes:
Ejecución de transacciones en paralelo con múltiples hilos: configurar varios hilos para procesar diferentes transacciones simultáneamente, sin interferencia entre ellos. Esto puede aumentar varias veces la velocidad de procesamiento de transacciones.
Asignar una base de datos de estado temporal para cada hilo: asignar una base de datos de estado temporal independiente (pending-stateDB) para cada hilo. Cada hilo, al ejecutar transacciones, no modifica directamente el stateDB global, sino que registra temporalmente los resultados de los cambios de estado en la pending-stateDB.
Sincronización de cambios de estado: Una vez que se han completado todas las transacciones dentro de un bloque, la EVM sincronizará secuencialmente los resultados de los cambios de estado registrados en cada pending-stateDB en el stateDB global. Si no hay conflictos de estado durante la ejecución de diferentes transacciones, se pueden fusionar sin problemas los registros del pending-stateDB en el stateDB global.
El proyecto ha optimizado la forma en que se manejan las operaciones de lectura y escritura para garantizar 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 requeridos, se leen directamente del pending-stateDB. Si no se encuentra el par clave-valor correspondiente en el ReadSet, se leen los datos de estado histórico del global stateDB del bloque anterior.
Operaciones de escritura: Todas las operaciones de escritura (, es decir, las modificaciones al estado ), no se escriben directamente en la 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 los resultados de los cambios de estado en la stateDB global a través de la detección de conflictos.
La clave del problema de la ejecución paralela radica en los conflictos de estado; este problema es particularmente notable cuando múltiples transacciones intentan leer y escribir el estado de la misma cuenta. Para ello, se introduce un mecanismo de detección de conflictos:
Detección de conflictos: Durante el proceso de 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 marcará como necesaria para su reejecución.
Después de que se completen todas las transacciones, los registros de cambios en múltiples stateDB en estado pendiente se combinarán en el stateDB global. Si la combinación tiene éxito, el EVM enviará el estado final al árbol de estado global y generará una nueva raíz de estado.
La optimización de la paralelización multihilo tiene un impacto significativo en el rendimiento, especialmente al manejar transacciones complejas de contratos inteligentes. Las investigaciones muestran que, en un grupo de transacciones con baja carga de conflictos (, donde hay menos contradicciones o transacciones que ocupan los mismos recursos ), el TPS de las pruebas de referencia se incrementó aproximadamente entre 3 y 5 veces en comparación con la ejecución secuencial tradicional. En cargas de trabajo de alta conflictividad, teóricamente, si se aplican todas las medidas de optimización, se podría alcanzar incluso un aumento de hasta 60 veces.
Resumen
La solución de optimización de paralelismo multihilo de EVM del proyecto, asignando una biblioteca de estado temporal a cada transacción y ejecutando transacciones en paralelo en diferentes hilos, ha mejorado 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 masiva de transacciones, garantizando la consistencia del estado, resolviendo así el cuello de botella de rendimiento que presenta el modo de ejecución serial tradicional. Esto sienta una base importante para el futuro desarrollo de Rollup de Ethereum.