Optimización de paralelización de EVM: Mejora de la eficiencia del procesamiento de transacciones de Ethereum
EVM como el motor de ejecución central de Ethereum, su posición es "entorno de ejecución de contratos inteligentes". Para asegurar que los contratos inteligentes obtengan resultados consistentes en diferentes nodos, EVM proporciona un entorno de máquina virtual multiplataforma, similar a la máquina virtual Java JVM.
Los contratos inteligentes se compilan en código de bytes EVM y se almacenan en la cadena al ser desplegados. Al ejecutar el contrato, EVM lee estas instrucciones de bytes en secuencia, 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.
El EVM tradicional procesa las transacciones de manera secuencial, ejecutando todas las transacciones en una única cola en un orden determinado. Este diseño es simple y fácil de mantener, pero a medida que aumenta la escala de usuarios y se aplica la tecnología Rollup, el cuello de botella en el rendimiento de la ejecución secuencial se vuelve cada vez más evidente.
En la arquitectura Rollup, el Sequencer, como componente clave de Layer2, asume todas las tareas de cálculo. Si otros módulos externos son lo suficientemente eficientes, la ejecución en serie del Sequencer se convertirá en el mayor cuello de botella. Hay equipos que, a través de una optimización extrema, han logrado que el Sequencer pueda ejecutar más de 2000 transferencias ERC-20 por segundo, pero para transacciones más complejas, el TPS aún disminuirá drásticamente. Por lo tanto, la paralelización del procesamiento de transacciones se convierte en la tendencia de desarrollo futura.
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. Ethereum utiliza una estructura de árbol Merkle Patricia Trie como índice de base de datos, y cada vez que se ejecuta una transacción en EVM, se modifican los datos en stateDB, que finalmente se reflejan en el árbol de estado global.
stateDB se encarga de mantener el estado de todas las cuentas de Ethereum, incluyendo el saldo de cuentas, el código de contratos inteligentes, etc. Durante el proceso de ejecución de la transacción, stateDB lee y escribe los datos de las cuentas correspondientes, y después de que la ejecución haya finalizado, envía el nuevo estado a la base de datos subyacente para su persistencia.
EVM y stateDB colaboran para construir el entorno de ejecución de transacciones de Ethereum. EVM se encarga de interpretar y ejecutar las instrucciones de los contratos inteligentes, cambiando el estado de la cadena de bloques 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.
En el modo de ejecución en serie, las transacciones dentro de un bloque se procesan una por una en orden. Cada transacción utiliza una instancia independiente de EVM, pero todas las transacciones comparten la misma stateDB. Durante el proceso de ejecución, el EVM necesita interactuar continuamente con la stateDB, leyendo datos relevantes y escribiendo los resultados de los cambios.
Después de que se completen todas las transacciones dentro del bloque, los datos en stateDB se enviarán al árbol de estado global, generando una nueva raíz de estado. Este modo de ejecución en serie tiene como principal limitación que las transacciones deben ejecutarse en cola, lo que impide aprovechar plenamente los recursos de hardware, especialmente cuando se enfrentan a transacciones complejas de contratos inteligentes, lo que resulta en una eficiencia más baja.
Para mejorar la eficiencia del procesamiento de transacciones, algunos proyectos han comenzado a intentar la optimización de múltiples hilos en EVM. Esto es similar a que un banco abra múltiples ventanillas para atender a los clientes al mismo tiempo, lo que puede aumentar la velocidad de procesamiento varias veces, pero es necesario resolver los posibles problemas de conflictos de estado.
Un proyecto de ZKRollup tiene la idea de optimización paralela para EVM asignando una base de datos de estado temporal a cada hilo (pending-stateDB). La implementación específica incluye:
Ejecución de transacciones en paralelo mediante múltiples hilos, sin interferencias entre sí.
Cada hilo tiene su propia pending-stateDB, y los cambios de estado se registran aquí durante la ejecución de la transacción.
Después de que se ejecuten todas las transacciones, se sincronizarán los cambios en pending-stateDB con el stateDB global.
Esta solución optimiza las operaciones de lectura y escritura:
Al realizar operaciones de lectura, primero se debe verificar el ReadSet de pending-stateDB; si se necesita algún dato, se lee directamente, de lo contrario, se lee el estado histórico desde el stateDB global.
Las operaciones de escritura no se escriben directamente en el stateDB global, sino que primero se registran en el WriteSet del pending-stateDB.
Para manejar conflictos de estado, se ha introducido un mecanismo de detección de conflictos:
Monitorear el ReadSet y WriteSet de diferentes transacciones, considerando como conflicto cuando múltiples transacciones leen y escriben el mismo elemento de estado.
Las transacciones en conflicto serán marcadas como necesarias para reejecutar.
Después de la ejecución de todas las transacciones, los registros de cambios de múltiples pending-stateDB se fusionarán en el stateDB global, y después de ser exitoso, se enviarán al árbol de estado global y generarán una nueva raíz de estado.
Los estudios muestran que, en cargas de trabajo de bajo conflicto, el TPS de EVM paralelo se mejora entre 3 y 5 veces en comparación con la ejecución serial tradicional. En cargas de trabajo de alto conflicto, teóricamente puede alcanzar una mejora de hasta 60 veces.
Esta solución de optimización paralela multihilo, a través de una biblioteca de estados temporales y ejecución en paralelo, ha mejorado significativamente la capacidad de procesamiento de transacciones de EVM. La optimización de las operaciones de lectura y escritura y la introducción de un mecanismo de detección de conflictos permiten lograr una paralelización masiva de transacciones mientras se garantiza la consistencia del estado, superando el cuello de botella de rendimiento de la ejecución en serie, sentando las bases para el desarrollo futuro 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.
10 me gusta
Recompensa
10
5
Compartir
Comentar
0/400
AirdropHunterZhang
· 07-29 02:07
No más, todos los días 60 veces, la crepe sigue a este precio.
Ver originalesResponder0
GateUser-afe07a92
· 07-28 22:11
Solo es un aumento en el TPS.
Ver originalesResponder0
ZKProofEnthusiast
· 07-28 22:09
¿El maestro puede tener una privacidad en cadena tan rápida como tps?
Ver originalesResponder0
¯\_(ツ)_/¯
· 07-28 21:56
Sigue minería, así es como quiero.
Ver originalesResponder0
GateUser-aa7df71e
· 07-28 21:48
introducir una posición, hermanos, Gran aumento de TPS está por llegar
Optimización de paralelismo EVM: mejora de la eficiencia del procesamiento de transacciones de Ethereum de 5 a 60 veces
Optimización de paralelización de EVM: Mejora de la eficiencia del procesamiento de transacciones de Ethereum
EVM como el motor de ejecución central de Ethereum, su posición es "entorno de ejecución de contratos inteligentes". Para asegurar que los contratos inteligentes obtengan resultados consistentes en diferentes nodos, EVM proporciona un entorno de máquina virtual multiplataforma, similar a la máquina virtual Java JVM.
Los contratos inteligentes se compilan en código de bytes EVM y se almacenan en la cadena al ser desplegados. Al ejecutar el contrato, EVM lee estas instrucciones de bytes en secuencia, 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.
El EVM tradicional procesa las transacciones de manera secuencial, ejecutando todas las transacciones en una única cola en un orden determinado. Este diseño es simple y fácil de mantener, pero a medida que aumenta la escala de usuarios y se aplica la tecnología Rollup, el cuello de botella en el rendimiento de la ejecución secuencial se vuelve cada vez más evidente.
En la arquitectura Rollup, el Sequencer, como componente clave de Layer2, asume todas las tareas de cálculo. Si otros módulos externos son lo suficientemente eficientes, la ejecución en serie del Sequencer se convertirá en el mayor cuello de botella. Hay equipos que, a través de una optimización extrema, han logrado que el Sequencer pueda ejecutar más de 2000 transferencias ERC-20 por segundo, pero para transacciones más complejas, el TPS aún disminuirá drásticamente. Por lo tanto, la paralelización del procesamiento de transacciones se convierte en la tendencia de desarrollo futura.
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. Ethereum utiliza una estructura de árbol Merkle Patricia Trie como índice de base de datos, y cada vez que se ejecuta una transacción en EVM, se modifican los datos en stateDB, que finalmente se reflejan en el árbol de estado global.
stateDB se encarga de mantener el estado de todas las cuentas de Ethereum, incluyendo el saldo de cuentas, el código de contratos inteligentes, etc. Durante el proceso de ejecución de la transacción, stateDB lee y escribe los datos de las cuentas correspondientes, y después de que la ejecución haya finalizado, envía el nuevo estado a la base de datos subyacente para su persistencia.
EVM y stateDB colaboran para construir el entorno de ejecución de transacciones de Ethereum. EVM se encarga de interpretar y ejecutar las instrucciones de los contratos inteligentes, cambiando el estado de la cadena de bloques 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.
En el modo de ejecución en serie, las transacciones dentro de un bloque se procesan una por una en orden. Cada transacción utiliza una instancia independiente de EVM, pero todas las transacciones comparten la misma stateDB. Durante el proceso de ejecución, el EVM necesita interactuar continuamente con la stateDB, leyendo datos relevantes y escribiendo los resultados de los cambios.
Después de que se completen todas las transacciones dentro del bloque, los datos en stateDB se enviarán al árbol de estado global, generando una nueva raíz de estado. Este modo de ejecución en serie tiene como principal limitación que las transacciones deben ejecutarse en cola, lo que impide aprovechar plenamente los recursos de hardware, especialmente cuando se enfrentan a transacciones complejas de contratos inteligentes, lo que resulta en una eficiencia más baja.
Para mejorar la eficiencia del procesamiento de transacciones, algunos proyectos han comenzado a intentar la optimización de múltiples hilos en EVM. Esto es similar a que un banco abra múltiples ventanillas para atender a los clientes al mismo tiempo, lo que puede aumentar la velocidad de procesamiento varias veces, pero es necesario resolver los posibles problemas de conflictos de estado.
Un proyecto de ZKRollup tiene la idea de optimización paralela para EVM asignando una base de datos de estado temporal a cada hilo (pending-stateDB). La implementación específica incluye:
Ejecución de transacciones en paralelo mediante múltiples hilos, sin interferencias entre sí.
Cada hilo tiene su propia pending-stateDB, y los cambios de estado se registran aquí durante la ejecución de la transacción.
Después de que se ejecuten todas las transacciones, se sincronizarán los cambios en pending-stateDB con el stateDB global.
Esta solución optimiza las operaciones de lectura y escritura:
Al realizar operaciones de lectura, primero se debe verificar el ReadSet de pending-stateDB; si se necesita algún dato, se lee directamente, de lo contrario, se lee el estado histórico desde el stateDB global.
Las operaciones de escritura no se escriben directamente en el stateDB global, sino que primero se registran en el WriteSet del pending-stateDB.
Para manejar conflictos de estado, se ha introducido un mecanismo de detección de conflictos:
Monitorear el ReadSet y WriteSet de diferentes transacciones, considerando como conflicto cuando múltiples transacciones leen y escriben el mismo elemento de estado.
Las transacciones en conflicto serán marcadas como necesarias para reejecutar.
Después de la ejecución de todas las transacciones, los registros de cambios de múltiples pending-stateDB se fusionarán en el stateDB global, y después de ser exitoso, se enviarán al árbol de estado global y generarán una nueva raíz de estado.
Los estudios muestran que, en cargas de trabajo de bajo conflicto, el TPS de EVM paralelo se mejora entre 3 y 5 veces en comparación con la ejecución serial tradicional. En cargas de trabajo de alto conflicto, teóricamente puede alcanzar una mejora de hasta 60 veces.
Esta solución de optimización paralela multihilo, a través de una biblioteca de estados temporales y ejecución en paralelo, ha mejorado significativamente la capacidad de procesamiento de transacciones de EVM. La optimización de las operaciones de lectura y escritura y la introducción de un mecanismo de detección de conflictos permiten lograr una paralelización masiva de transacciones mientras se garantiza la consistencia del estado, superando el cuello de botella de rendimiento de la ejecución en serie, sentando las bases para el desarrollo futuro de Rollup de Ethereum.