El camino de la optimización de la paralelización en EVM
Como todos saben, EVM es uno de los componentes centrales más importantes de Ethereum, desempeñando un papel clave como "motor de ejecución" y "entorno de ejecución de contratos inteligentes". En una red de cadena pública compuesta por miles de nodos, la existencia de la máquina virtual permite que los contratos inteligentes se ejecuten de la misma manera en nodos con diferentes configuraciones de hardware, asegurando la consistencia de los resultados. Esta compatibilidad multiplataforma es bastante similar a la máquina virtual de Java, JVM.
Los contratos inteligentes se compilan en código de bytes EVM antes de ser subidos a la cadena. Al ejecutar un contrato, EVM lee secuencialmente este código de bytes, y cada instrucción tiene un costo de Gas correspondiente. EVM rastrea el consumo de Gas durante la ejecución de las instrucciones, y la cantidad consumida depende de la complejidad de la operación.
Como el motor de ejecución central de Ethereum, EVM maneja las transacciones mediante una ejecución en serie. Todas las transacciones se colocan en una única cola y se ejecutan en un orden determinado. Este diseño es simple y fácil de mantener, pero a medida que la base de usuarios se expande y la tecnología avanza, sus cuellos de botella de rendimiento se vuelven cada vez más evidentes, especialmente después de que la tecnología Rollup madura, lo que se manifiesta de manera particularmente notable en las redes de segunda capa de Ethereum.
El secuenciador, como componente clave de Layer2, asume todas las tareas de cálculo en forma de un solo servidor. Si los módulos externos asociados son lo suficientemente eficientes, el cuello de botella final dependerá de la eficiencia del secuenciador en sí, y 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, lo que permite que el Sequencer ejecute más de 2000 transferencias ERC-20 por segundo. Este número parece alto, pero para transacciones complejas, el valor de TPS inevitablemente se verá afectado. 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 Merkle Patricia Trie como índice de base de datos, y cada ejecución de transacción en EVM modifica ciertos datos en stateDB, cambios que finalmente se reflejan en el árbol de estado global.
stateDB es responsable 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, 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 persistente.
En general, el 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 el 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 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, con una velocidad de procesamiento muy rápida y tarifas de gas extremadamente bajas.
El comercio de contratos implica la llamada 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 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 lógica compleja como pools de liquidez, cálculo de precios, intercambio de tokens, entre otros, lo que requiere cálculos muy complejos.
En el modo de ejecución en serie, el proceso de colaboración entre EVM y stateDB es el siguiente:
Las transacciones dentro del bloque se procesan una por una en orden cronológico, cada transacción tiene una instancia independiente que ejecuta operaciones específicas.
Aunque cada transacción utiliza una instancia EVM diferente, 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 continuamente con stateDB, leer los datos relevantes y escribir los datos modificados de vuelta en stateDB.
Una vez que se completan todas las transacciones, los datos en stateDB se enviarán al árbol de estado global y se generará una nueva raíz de estado.
El modo de ejecución en serie de EVM presenta un claro cuello de botella: las transacciones deben ejecutarse en orden secuencial. Si hay transacciones de contratos inteligentes que tardan mucho tiempo, las demás transacciones solo pueden esperar, lo que impide un uso óptimo de los recursos de hardware y limita significativamente la eficiencia.
Solución de optimización de paralelismo multihilo de EVM
EVM paralelo es similar a un banco con múltiples ventanillas, donde se pueden abrir múltiples hilos para procesar varias transacciones simultáneamente, lo que puede aumentar la eficiencia varias veces. Pero el problema complicado es el conflicto de estados, que necesita ser manejado de manera coordinada.
La idea de optimización paralela de un proyecto ZKRollup para EVM es la siguiente:
Ejecución de transacciones en paralelo con múltiples hilos: Configura múltiples hilos para procesar diferentes transacciones simultáneamente, sin interferencia entre los hilos, lo que puede aumentar la velocidad de procesamiento de transacciones varias veces.
Asignar una base de datos de estado temporal para cada hilo: a cada hilo se le asigna una base de datos de estado temporal independiente (pending-stateDB). Cuando los hilos ejecutan transacciones, no modifican directamente la stateDB global, sino que registran 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 dentro de un bloque, el EVM sincroniza secuencialmente los resultados de los cambios de estado registrados en cada pending-stateDB con el stateDB global. Si no se producen conflictos de estado durante la ejecución de diferentes transacciones, se pueden fusionar con éxito los registros del pending-stateDB en el stateDB global.
El proyecto ha optimizado el manejo de 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 la transacción requiere leer el estado, la EVM primero verifica el ReadSet del estado pendiente. Si hay datos necesarios, se leen directamente de la base de datos del estado pendiente. Si no se encuentra el par clave-valor correspondiente en el ReadSet, se lee el historial de datos de estado de la base de datos del estado global correspondiente al bloque anterior.
Operaciones de escritura: todas las operaciones de escritura no se registran directamente en el stateDB global, sino que primero se registran en el WriteSet del estado pendiente. Una vez que se completa la ejecución de la transacción, se intenta fusionar los resultados de los cambios de estado en el stateDB global a través de la detección de conflictos.
Para resolver el problema de conflictos de estado, se introdujo un mecanismo de detección de conflictos:
Detección de conflictos: 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 reejecutarse.
Después de que se completen todas las transacciones, los registros de cambios en varios pending-stateDB se fusionarán en el stateDB global. Si la fusión es exitosa, el EVM enviará el estado final al árbol de estados global y generará una nueva raíz de estado.
La optimización de paralelismo multihilo mejora significativamente el rendimiento, especialmente al manejar transacciones de contratos inteligentes complejos. Los estudios muestran que, en cargas de trabajo de bajo conflicto, el TPS en pruebas de referencia se incrementó de 3 a 5 veces en comparación con la ejecución secuencial tradicional. En cargas de trabajo de alto conflicto, teóricamente, si se aplican todas las técnicas de optimización, se podría alcanzar incluso un aumento de 60 veces.
Resumen
La solución de optimización de paralelización 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. A través de la optimización de las operaciones de lectura y escritura y la introducción de mecanismos de detección de conflictos, las cadenas públicas de tipo EVM pueden lograr una paralelización masiva de transacciones, garantizando la consistencia del estado y resolviendo los cuellos 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.
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.
15 me gusta
Recompensa
15
6
Republicar
Compartir
Comentar
0/400
TokenVelocityTrauma
· 08-02 02:05
El cuello de botella en el rendimiento necesita ser mejorado.
Ver originalesResponder0
ForkPrince
· 07-30 22:41
Optimización y mejoras, muy esperado.
Ver originalesResponder0
MEVVictimAlliance
· 07-30 14:54
La eficiencia ha mejorado considerablemente
Ver originalesResponder0
FalseProfitProphet
· 07-30 10:43
La paralelización ha acelerado increíblemente.
Ver originalesResponder0
ShitcoinConnoisseur
· 07-30 10:42
El cuello de botella del rendimiento en serie es grande
Optimización de EVM: mejora de la eficiencia del procesamiento de transacciones mediante el paralelismo multihilo
El camino de la optimización de la paralelización en EVM
Como todos saben, EVM es uno de los componentes centrales más importantes de Ethereum, desempeñando un papel clave como "motor de ejecución" y "entorno de ejecución de contratos inteligentes". En una red de cadena pública compuesta por miles de nodos, la existencia de la máquina virtual permite que los contratos inteligentes se ejecuten de la misma manera en nodos con diferentes configuraciones de hardware, asegurando la consistencia de los resultados. Esta compatibilidad multiplataforma es bastante similar a la máquina virtual de Java, JVM.
Los contratos inteligentes se compilan en código de bytes EVM antes de ser subidos a la cadena. Al ejecutar un contrato, EVM lee secuencialmente este código de bytes, y cada instrucción tiene un costo de Gas correspondiente. EVM rastrea el consumo de Gas durante la ejecución de las instrucciones, y la cantidad consumida depende de la complejidad de la operación.
Como el motor de ejecución central de Ethereum, EVM maneja las transacciones mediante una ejecución en serie. Todas las transacciones se colocan en una única cola y se ejecutan en un orden determinado. Este diseño es simple y fácil de mantener, pero a medida que la base de usuarios se expande y la tecnología avanza, sus cuellos de botella de rendimiento se vuelven cada vez más evidentes, especialmente después de que la tecnología Rollup madura, lo que se manifiesta de manera particularmente notable en las redes de segunda capa de Ethereum.
El secuenciador, como componente clave de Layer2, asume todas las tareas de cálculo en forma de un solo servidor. Si los módulos externos asociados son lo suficientemente eficientes, el cuello de botella final dependerá de la eficiencia del secuenciador en sí, y 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, lo que permite que el Sequencer ejecute más de 2000 transferencias ERC-20 por segundo. Este número parece alto, pero para transacciones complejas, el valor de TPS inevitablemente se verá afectado. 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 Merkle Patricia Trie como índice de base de datos, y cada ejecución de transacción en EVM modifica ciertos datos en stateDB, cambios que finalmente se reflejan en el árbol de estado global.
stateDB es responsable 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, 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 persistente.
En general, el 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 el 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 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, con una velocidad de procesamiento muy rápida y tarifas de gas extremadamente bajas.
El comercio de contratos implica la llamada 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 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 lógica compleja como pools de liquidez, cálculo de precios, intercambio de tokens, entre otros, lo que requiere cálculos muy complejos.
En el modo de ejecución en serie, el proceso de colaboración entre EVM y stateDB es el siguiente:
El modo de ejecución en serie de EVM presenta un claro cuello de botella: las transacciones deben ejecutarse en orden secuencial. Si hay transacciones de contratos inteligentes que tardan mucho tiempo, las demás transacciones solo pueden esperar, lo que impide un uso óptimo de los recursos de hardware y limita significativamente la eficiencia.
Solución de optimización de paralelismo multihilo de EVM
EVM paralelo es similar a un banco con múltiples ventanillas, donde se pueden abrir múltiples hilos para procesar varias transacciones simultáneamente, lo que puede aumentar la eficiencia varias veces. Pero el problema complicado es el conflicto de estados, que necesita ser manejado de manera coordinada.
La idea de optimización paralela de un proyecto ZKRollup para EVM es la siguiente:
Ejecución de transacciones en paralelo con múltiples hilos: Configura múltiples hilos para procesar diferentes transacciones simultáneamente, sin interferencia entre los hilos, lo que puede aumentar la velocidad de procesamiento de transacciones varias veces.
Asignar una base de datos de estado temporal para cada hilo: a cada hilo se le asigna una base de datos de estado temporal independiente (pending-stateDB). Cuando los hilos ejecutan transacciones, no modifican directamente la stateDB global, sino que registran 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 dentro de un bloque, el EVM sincroniza secuencialmente los resultados de los cambios de estado registrados en cada pending-stateDB con el stateDB global. Si no se producen conflictos de estado durante la ejecución de diferentes transacciones, se pueden fusionar con éxito los registros del pending-stateDB en el stateDB global.
El proyecto ha optimizado el manejo de 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 la transacción requiere leer el estado, la EVM primero verifica el ReadSet del estado pendiente. Si hay datos necesarios, se leen directamente de la base de datos del estado pendiente. Si no se encuentra el par clave-valor correspondiente en el ReadSet, se lee el historial de datos de estado de la base de datos del estado global correspondiente al bloque anterior.
Operaciones de escritura: todas las operaciones de escritura no se registran directamente en el stateDB global, sino que primero se registran en el WriteSet del estado pendiente. Una vez que se completa la ejecución de la transacción, se intenta fusionar los resultados de los cambios de estado en el stateDB global a través de la detección de conflictos.
Para resolver el problema de conflictos de estado, se introdujo un mecanismo de detección de conflictos:
Después de que se completen todas las transacciones, los registros de cambios en varios pending-stateDB se fusionarán en el stateDB global. Si la fusión es exitosa, el EVM enviará el estado final al árbol de estados global y generará una nueva raíz de estado.
La optimización de paralelismo multihilo mejora significativamente el rendimiento, especialmente al manejar transacciones de contratos inteligentes complejos. Los estudios muestran que, en cargas de trabajo de bajo conflicto, el TPS en pruebas de referencia se incrementó de 3 a 5 veces en comparación con la ejecución secuencial tradicional. En cargas de trabajo de alto conflicto, teóricamente, si se aplican todas las técnicas de optimización, se podría alcanzar incluso un aumento de 60 veces.
Resumen
La solución de optimización de paralelización 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. A través de la optimización de las operaciones de lectura y escritura y la introducción de mecanismos de detección de conflictos, las cadenas públicas de tipo EVM pueden lograr una paralelización masiva de transacciones, garantizando la consistencia del estado y resolviendo los cuellos 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.