Exploración de los cuellos de botella en la ejecución en serie de EVM y optimización en paralelo
Como todos saben, EVM es el motor de ejecución central de Ethereum y el entorno de ejecución de contratos inteligentes, siendo uno de los componentes más críticos de Ethereum. En una red de cadena pública compuesta por numerosos nodos, la tecnología de máquinas virtuales juega un papel crucial para asegurar que los contratos inteligentes se ejecuten de manera consistente en diferentes nodos.
EVM puede ejecutar contratos inteligentes de manera uniforme en varios sistemas operativos y dispositivos, lo que garantiza que cada nodo obtenga resultados consistentes después de ejecutar el contrato. Esto es similar a cómo funciona la máquina virtual Java (JVM).
Normalmente, un contrato inteligente se compila primero en bytecode EVM y luego se almacena en la cadena de bloques. Cuando EVM ejecuta el contrato, lee estos bytecodes en orden, y cada instrucción tiene un costo específico de Gas. EVM rastrea el consumo de Gas durante la ejecución de cada instrucción, y la cantidad específica de consumo depende de la complejidad de la operación.
Como el motor de ejecución central de Ethereum, el EVM maneja las transacciones de manera secuencial, con todas las transacciones en una única cola y ejecutándose en el orden determinado. La razón para elegir la secuencialidad en lugar de la paralelización es para cumplir estrictamente con los requisitos de consistencia de la blockchain, asegurando que un lote de transacciones se procese en el mismo orden en todos los nodos.
Entre 2014 y 2015, el equipo fundador de Ethereum, debido a la urgencia de tiempo, optó por un enfoque de ejecución en serie que era simple y fácil de mantener. Sin embargo, con el desarrollo de la tecnología blockchain y la expansión de la base de usuarios, las demandas sobre TPS y capacidad de procesamiento han aumentado constantemente. En particular, después de que la tecnología Rollup maduró, los cuellos de botella de rendimiento causados por la ejecución en serie de EVM se han vuelto más evidentes en la red de segunda capa de Ethereum.
Como componente clave de Layer2, el Sequencer asume todas las tareas de cálculo en forma de un solo servidor. Si los módulos externos que trabajan con el Sequencer tienen suficiente eficiencia, el cuello de botella final dependerá de la eficiencia del Sequencer en sí, momento en el cual la ejecución en serie se convertirá en un obstáculo significativo.
Un equipo ha optimizado al máximo la capa DA y el módulo de lectura y escritura de datos, lo que permite que el Secuenciador ejecute más de 2000 transferencias ERC-20 por segundo. Este número parece muy alto, pero para transacciones más complejas, el valor de TPS inevitablemente disminuirá drásticamente. Por lo tanto, la paralelización del procesamiento de transacciones será una tendencia inevitable en el futuro.
Dos componentes clave para la ejecución de transacciones en Ethereum
Además de EVM, otro componente central relacionado con la ejecución de transacciones 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 Merkle Patricia Trie como índice de base de datos, y cada ejecución de transacción por parte de EVM altera ciertos datos en stateDB, y estos cambios finalmente se reflejarán en el árbol de estado global.
stateDB se encarga de mantener el estado de todas las cuentas de Ethereum, incluidas las cuentas EOA y las cuentas de contrato, y los datos almacenados incluyen el saldo de la cuenta, el código del contrato inteligente, etc. Durante el proceso de ejecución de la transacción, stateDB realiza lecturas y escrituras de 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 se encarga 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 los cambios de estado de todas las cuentas y contratos. Ambos construyen 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 dos: transferencias EOA y transacciones de contrato. La transferencia EOA es el tipo de transacción más simple, es decir, la transferencia de ETH entre cuentas normales, sin involucrar llamadas a contratos, con una velocidad de procesamiento muy rápida y una tarifa de gas muy baja.
En comparación, el comercio de contratos implica la invocación y ejecución de contratos inteligentes. EVM, al procesar transacciones de contratos, necesita interpretar y ejecutar línea por línea las instrucciones de bytecode en el 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 una transferencia ERC-20 es aproximadamente el doble que el de una transferencia EOA, mientras que las operaciones más complejas de contratos inteligentes, 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 lógica compleja, como pools de liquidez, cálculos de precios y intercambios de tokens durante las transacciones, lo que implica un gran volumen de cálculos.
En el modo de ejecución en serie, el proceso en el que EVM y stateDB colaboran para procesar transacciones es el siguiente:
En el diseño de Ethereum, las transacciones dentro de un bloque se procesan una por una en orden secuencial, y cada transacción tiene una instancia independiente para ejecutar operaciones específicas. 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 transacciones, EVM necesita interactuar constantemente con stateDB, leyendo datos relevantes de stateDB y escribiendo los datos modificados de nuevo en stateDB.
Una vez que 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.
Evidentemente, el modo de ejecución en serie de EVM presenta un claro cuello de botella: las transacciones deben ejecutarse en orden secuencial y, si hay una transacción de contrato inteligente que toma mucho tiempo, las otras transacciones solo pueden esperar, no se pueden aprovechar plenamente los recursos del hardware, lo que limita significativamente la eficiencia.
Solución de optimización de paralelismo multihilo para EVM
Si hacemos una analogía con ejemplos de la vida cotidiana, la ejecución en serie es como un banco con solo un ventanilla, mientras que el EVM paralelo es similar a un banco con múltiples ventanillas. En modo paralelo, se pueden abrir múltiples hilos para procesar varias transacciones al mismo tiempo, lo que puede aumentar la eficiencia varias veces, pero es necesario resolver el problema de conflictos de estado.
Si varias transacciones declaran modificar los datos de una cuenta, se generará un conflicto al procesarlas simultáneamente. Por ejemplo, un NFT solo puede ser acuñado una vez, y si la transacción 1 y la transacción 2 declaran acuñar ese NFT, si ambas solicitudes se satisfacen, claramente habrá un error. En la práctica, los conflictos de estado son mucho más frecuentes, por lo que el procesamiento en paralelo debe tener medidas para enfrentar estos conflictos de estado.
Principio de optimización paralela de EVM de un proyecto determinado
Un proyecto 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: configura varios hilos para procesar diferentes transacciones simultáneamente, sin interferir entre sí, lo que puede aumentar la velocidad de procesamiento de transacciones varias veces.
Asignar una base de datos de estado temporal a cada hilo: Asigne una base de datos de estado temporal independiente (pending-stateDB) a cada hilo. Cada hilo, al ejecutar transacciones, no modifica directamente la base de datos de estado global (stateDB), sino que registra temporalmente los resultados de los cambios de estado en la pending-stateDB.
Sincronización de cambios de estado: Después de que se completen todas las transacciones en un bloque, el EVM sincronizará secuencialmente los resultados de los cambios de estado registrados en cada pending-stateDB al 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, EVM primero verifica el ReadSet del estado pendiente. Si los datos necesarios están en el ReadSet, se leen directamente de la base de datos del estado pendiente (pending-stateDB). Si no se encuentra el par clave-valor correspondiente en el ReadSet, se leen los datos del estado histórico de la base de datos global del bloque anterior.
Operaciones de escritura: todas las operaciones de escritura (es decir, las modificaciones al estado) no se escriben directamente en el stateDB global, sino que primero se registran en el WriteSet del estado pendiente. Una vez que la transacción se completa, se intenta fusionar los resultados del cambio de estado en el stateDB global mediante la detección de conflictos.
La cuestión clave de la ejecución paralela radica en los conflictos de estado, que se vuelve especialmente notable cuando múltiples transacciones intentan leer y escribir el estado de la misma cuenta. Para ello, se ha introducido un mecanismo de detección de conflictos:
Detección de conflictos: durante el proceso de ejecución de transacciones, la EVM monitorea el ReadSet y el WriteSet de diferentes transacciones. Si se detecta que varias 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 ejecuciones de transacciones, los registros de cambios en múltiples pending-stateDB se fusionarán en el stateDB global. Si la fusión es exitosa, la 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 cargas de trabajo de bajo conflicto, el TPS de las pruebas de referencia se incrementa entre 3 y 5 veces en comparación con la ejecución serial tradicional. En cargas de trabajo de alto conflicto, teóricamente, si se aplican todas las medidas de optimización, se podría alcanzar incluso un aumento de 60 veces.
Resumen
La solución de optimización de paralelismo multihilo de EVM mejora significativamente la capacidad de procesamiento de transacciones de EVM al asignar una biblioteca de estado temporal a cada transacción y ejecutar las transacciones en paralelo en diferentes hilos. Al optimizar las operaciones de lectura y escritura e introducir mecanismos de detección de conflictos, las cadenas públicas de la serie EVM pueden lograr una paralelización masiva de transacciones bajo la premisa de garantizar la consistencia del estado, resolviendo el cuello de botella de rendimiento que presenta el modo de ejecución serial tradicional. Esto sienta una base importante para el desarrollo futuro de Ethereum Rollup.
En el futuro, también se puede explorar cómo optimizar la eficiencia del almacenamiento para mejorar el rendimiento, las soluciones de optimización en casos de alta contienda, y cómo utilizar la GPU para la optimización, entre otros temas.
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.
9 me gusta
Recompensa
9
3
Compartir
Comentar
0/400
LeverageAddict
· 07-20 10:07
Ya hay alguien haciendo paralelismo, igual que mi posición L2, está igual de atascada.
Ver originalesResponder0
WenMoon
· 07-20 09:51
¡Ugh! L2 también necesita acelerarse.
Ver originalesResponder0
EntryPositionAnalyst
· 07-20 09:44
L2 paralelización ya se ha entendido bien, ahora solo sigo el evm.
Optimización de paralelización de EVM: superación del cuello de botella de ejecución en serie y mejora del rendimiento de Layer2
Exploración de los cuellos de botella en la ejecución en serie de EVM y optimización en paralelo
Como todos saben, EVM es el motor de ejecución central de Ethereum y el entorno de ejecución de contratos inteligentes, siendo uno de los componentes más críticos de Ethereum. En una red de cadena pública compuesta por numerosos nodos, la tecnología de máquinas virtuales juega un papel crucial para asegurar que los contratos inteligentes se ejecuten de manera consistente en diferentes nodos.
EVM puede ejecutar contratos inteligentes de manera uniforme en varios sistemas operativos y dispositivos, lo que garantiza que cada nodo obtenga resultados consistentes después de ejecutar el contrato. Esto es similar a cómo funciona la máquina virtual Java (JVM).
Normalmente, un contrato inteligente se compila primero en bytecode EVM y luego se almacena en la cadena de bloques. Cuando EVM ejecuta el contrato, lee estos bytecodes en orden, y cada instrucción tiene un costo específico de Gas. EVM rastrea el consumo de Gas durante la ejecución de cada instrucción, y la cantidad específica de consumo depende de la complejidad de la operación.
Como el motor de ejecución central de Ethereum, el EVM maneja las transacciones de manera secuencial, con todas las transacciones en una única cola y ejecutándose en el orden determinado. La razón para elegir la secuencialidad en lugar de la paralelización es para cumplir estrictamente con los requisitos de consistencia de la blockchain, asegurando que un lote de transacciones se procese en el mismo orden en todos los nodos.
Entre 2014 y 2015, el equipo fundador de Ethereum, debido a la urgencia de tiempo, optó por un enfoque de ejecución en serie que era simple y fácil de mantener. Sin embargo, con el desarrollo de la tecnología blockchain y la expansión de la base de usuarios, las demandas sobre TPS y capacidad de procesamiento han aumentado constantemente. En particular, después de que la tecnología Rollup maduró, los cuellos de botella de rendimiento causados por la ejecución en serie de EVM se han vuelto más evidentes en la red de segunda capa de Ethereum.
Como componente clave de Layer2, el Sequencer asume todas las tareas de cálculo en forma de un solo servidor. Si los módulos externos que trabajan con el Sequencer tienen suficiente eficiencia, el cuello de botella final dependerá de la eficiencia del Sequencer en sí, momento en el cual la ejecución en serie se convertirá en un obstáculo significativo.
Un equipo ha optimizado al máximo la capa DA y el módulo de lectura y escritura de datos, lo que permite que el Secuenciador ejecute más de 2000 transferencias ERC-20 por segundo. Este número parece muy alto, pero para transacciones más complejas, el valor de TPS inevitablemente disminuirá drásticamente. Por lo tanto, la paralelización del procesamiento de transacciones será una tendencia inevitable en el futuro.
Dos componentes clave para la ejecución de transacciones en Ethereum
Además de EVM, otro componente central relacionado con la ejecución de transacciones 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 Merkle Patricia Trie como índice de base de datos, y cada ejecución de transacción por parte de EVM altera ciertos datos en stateDB, y estos cambios finalmente se reflejarán en el árbol de estado global.
stateDB se encarga de mantener el estado de todas las cuentas de Ethereum, incluidas las cuentas EOA y las cuentas de contrato, y los datos almacenados incluyen el saldo de la cuenta, el código del contrato inteligente, etc. Durante el proceso de ejecución de la transacción, stateDB realiza lecturas y escrituras de 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 se encarga 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 los cambios de estado de todas las cuentas y contratos. Ambos construyen 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 dos: transferencias EOA y transacciones de contrato. La transferencia EOA es el tipo de transacción más simple, es decir, la transferencia de ETH entre cuentas normales, sin involucrar llamadas a contratos, con una velocidad de procesamiento muy rápida y una tarifa de gas muy baja.
En comparación, el comercio de contratos implica la invocación y ejecución de contratos inteligentes. EVM, al procesar transacciones de contratos, necesita interpretar y ejecutar línea por línea las instrucciones de bytecode en el 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 una transferencia ERC-20 es aproximadamente el doble que el de una transferencia EOA, mientras que las operaciones más complejas de contratos inteligentes, 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 lógica compleja, como pools de liquidez, cálculos de precios y intercambios de tokens durante las transacciones, lo que implica un gran volumen de cálculos.
En el modo de ejecución en serie, el proceso en el que EVM y stateDB colaboran para procesar transacciones es el siguiente:
En el diseño de Ethereum, las transacciones dentro de un bloque se procesan una por una en orden secuencial, y cada transacción tiene una instancia independiente para ejecutar operaciones específicas. 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 transacciones, EVM necesita interactuar constantemente con stateDB, leyendo datos relevantes de stateDB y escribiendo los datos modificados de nuevo en stateDB.
Una vez que 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.
Evidentemente, el modo de ejecución en serie de EVM presenta un claro cuello de botella: las transacciones deben ejecutarse en orden secuencial y, si hay una transacción de contrato inteligente que toma mucho tiempo, las otras transacciones solo pueden esperar, no se pueden aprovechar plenamente los recursos del hardware, lo que limita significativamente la eficiencia.
Solución de optimización de paralelismo multihilo para EVM
Si hacemos una analogía con ejemplos de la vida cotidiana, la ejecución en serie es como un banco con solo un ventanilla, mientras que el EVM paralelo es similar a un banco con múltiples ventanillas. En modo paralelo, se pueden abrir múltiples hilos para procesar varias transacciones al mismo tiempo, lo que puede aumentar la eficiencia varias veces, pero es necesario resolver el problema de conflictos de estado.
Si varias transacciones declaran modificar los datos de una cuenta, se generará un conflicto al procesarlas simultáneamente. Por ejemplo, un NFT solo puede ser acuñado una vez, y si la transacción 1 y la transacción 2 declaran acuñar ese NFT, si ambas solicitudes se satisfacen, claramente habrá un error. En la práctica, los conflictos de estado son mucho más frecuentes, por lo que el procesamiento en paralelo debe tener medidas para enfrentar estos conflictos de estado.
Principio de optimización paralela de EVM de un proyecto determinado
Un proyecto 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: configura varios hilos para procesar diferentes transacciones simultáneamente, sin interferir entre sí, lo que puede aumentar la velocidad de procesamiento de transacciones varias veces.
Asignar una base de datos de estado temporal a cada hilo: Asigne una base de datos de estado temporal independiente (pending-stateDB) a cada hilo. Cada hilo, al ejecutar transacciones, no modifica directamente la base de datos de estado global (stateDB), sino que registra temporalmente los resultados de los cambios de estado en la pending-stateDB.
Sincronización de cambios de estado: Después de que se completen todas las transacciones en un bloque, el EVM sincronizará secuencialmente los resultados de los cambios de estado registrados en cada pending-stateDB al 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, EVM primero verifica el ReadSet del estado pendiente. Si los datos necesarios están en el ReadSet, se leen directamente de la base de datos del estado pendiente (pending-stateDB). Si no se encuentra el par clave-valor correspondiente en el ReadSet, se leen los datos del estado histórico de la base de datos global del bloque anterior.
Operaciones de escritura: todas las operaciones de escritura (es decir, las modificaciones al estado) no se escriben directamente en el stateDB global, sino que primero se registran en el WriteSet del estado pendiente. Una vez que la transacción se completa, se intenta fusionar los resultados del cambio de estado en el stateDB global mediante la detección de conflictos.
La cuestión clave de la ejecución paralela radica en los conflictos de estado, que se vuelve especialmente notable cuando múltiples transacciones intentan leer y escribir el estado de la misma cuenta. Para ello, se ha introducido un mecanismo de detección de conflictos:
Detección de conflictos: durante el proceso de ejecución de transacciones, la EVM monitorea el ReadSet y el WriteSet de diferentes transacciones. Si se detecta que varias 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 ejecuciones de transacciones, los registros de cambios en múltiples pending-stateDB se fusionarán en el stateDB global. Si la fusión es exitosa, la 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 cargas de trabajo de bajo conflicto, el TPS de las pruebas de referencia se incrementa entre 3 y 5 veces en comparación con la ejecución serial tradicional. En cargas de trabajo de alto conflicto, teóricamente, si se aplican todas las medidas de optimización, se podría alcanzar incluso un aumento de 60 veces.
Resumen
La solución de optimización de paralelismo multihilo de EVM mejora significativamente la capacidad de procesamiento de transacciones de EVM al asignar una biblioteca de estado temporal a cada transacción y ejecutar las transacciones en paralelo en diferentes hilos. Al optimizar las operaciones de lectura y escritura e introducir mecanismos de detección de conflictos, las cadenas públicas de la serie EVM pueden lograr una paralelización masiva de transacciones bajo la premisa de garantizar la consistencia del estado, resolviendo el cuello de botella de rendimiento que presenta el modo de ejecución serial tradicional. Esto sienta una base importante para el desarrollo futuro de Ethereum Rollup.
En el futuro, también se puede explorar cómo optimizar la eficiencia del almacenamiento para mejorar el rendimiento, las soluciones de optimización en casos de alta contienda, y cómo utilizar la GPU para la optimización, entre otros temas.