Optimización de la paralelización de EVM: clave para mejorar el rendimiento de la Cadena de bloques
EVM, como el motor de ejecución central de Ethereum, siempre ha utilizado un enfoque secuencial para procesar transacciones. Este método, aunque simple y fácil de mantener, ha mostrado cada vez más sus cuellos de botella en rendimiento con la expansión de la base de usuarios y los avances tecnológicos. Especialmente hoy en día, con la amplia aplicación de la tecnología Rollup, la ejecución secuencial de EVM se ha convertido en un factor limitante importante para el desarrollo de la red de segunda capa.
El Sequencer, como componente central de Layer2, asume todas las tareas de cálculo en forma de un solo servidor. Cuando otros módulos tienen suficiente eficiencia, la capacidad de procesamiento del Sequencer se convierte en el cuello de botella final. Algunos equipos han optimizado la capa DA y los módulos de lectura y escritura de datos, permitiendo que el Sequencer ejecute aproximadamente 2000 transferencias ERC-20 por segundo. Este número parece no ser bajo, pero ante transacciones más complejas, el TPS necesariamente disminuirá drásticamente. Por lo tanto, la paralelización del procesamiento de transacciones se convierte en una tendencia inevitable para el desarrollo futuro.
En la estructura del código de Ethereum, además de EVM, stateDB también es un componente central estrechamente relacionado con la ejecución de transacciones. Es responsable de gestionar el estado de las cuentas y el almacenamiento de datos de Ethereum. Cada vez que EVM ejecuta una transacción, cambia ciertos datos en stateDB, y estos cambios finalmente se reflejan en el árbol de estado global.
stateDB mantiene principalmente el estado de todas las cuentas de Ethereum, incluyendo cuentas normales y cuentas de contrato, almacenando el saldo de la cuenta, el código del contrato inteligente y otra información. Durante el proceso de ejecución de la transacción, stateDB lee y escribe los datos de la cuenta correspondiente, y después de que la ejecución finaliza, envía el nuevo estado a la base de datos subyacente para su almacenamiento permanente.
En el modo de ejecución secuencial tradicional, las transacciones dentro de un Bloquear se procesan una por una en orden. Cada transacción tiene una instancia de EVM independiente que ejecuta operaciones específicas, pero todas las transacciones comparten la misma stateDB. Durante el proceso de ejecución, el EVM necesita interactuar frecuentemente con la stateDB, leyendo y escribiendo datos relevantes.
El defecto de este modo de ejecución en serie es muy evidente: las transacciones deben esperar en una cola para ser ejecutadas. Si se encuentra con una transacción de contrato complejo que consume mucho tiempo, las transacciones posteriores solo pueden esperar forzosamente, sin poder aprovechar plenamente los recursos de hardware, lo que limita gravemente la eficiencia de procesamiento.
Para superar este cuello de botella, la industria ha propuesto un esquema de optimización de múltiples hilos paralelo para EVM. La idea central es abrir múltiples hilos para procesar varias transacciones al mismo tiempo, lo que aumenta considerablemente la eficiencia. Sin embargo, el principal desafío de la ejecución paralela es cómo manejar el problema de conflictos de estado.
Un enfoque de optimización paralela de EVM en un proyecto merece atención. Asignan una transacción y una base de datos de estado temporal (pending-stateDB) a cada hilo. Los pasos específicos son los siguientes:
Ejecución paralela de transacciones en múltiples hilos, donde los hilos no interfieren entre sí.
Cada hilo tiene una pending-stateDB independiente, y durante la ejecución de la transacción, no modifica directamente la stateDB global, sino que almacena temporalmente los cambios de estado en la pending-stateDB.
Una vez que se hayan ejecutado todas las transacciones en el bloque, el EVM sincronizará sucesivamente los cambios de estado en cada pending-stateDB al stateDB global.
El proyecto también ha optimizado las operaciones de lectura y escritura:
Al realizar una operación de lectura, EVM primero verifica el ReadSet del estado pendiente. Si hay datos necesarios, se leen directamente de pending-stateDB; de lo contrario, se leen del stateDB global del bloque anterior.
Las operaciones de escritura no se escriben directamente en el stateDB global, sino que primero se registran en el WriteSet del estado pendiente. Una vez completada la ejecución de la transacción, se intenta fusionar en el stateDB global a través de la detección de conflictos.
Para resolver el problema de conflictos de estado, el proyecto introdujo un mecanismo de detección de conflictos:
Durante el proceso de ejecución, se monitorean los ReadSet y WriteSet de diferentes transacciones; si varias transacciones leen y escriben el mismo elemento de estado, se considera un conflicto.
Marcar transacciones en conflicto como necesarias para reejecutar.
Una vez que se ejecutan todas las transacciones, los registros de cambios del estado múltiple de pending-stateDB se combinan en el stateDB global. Después de una combinación exitosa, el estado final se envía al árbol de estado global, generando una nueva raíz de estado.
La optimización del paralelismo multihilo ha mejorado significativamente el rendimiento, especialmente al manejar transacciones complejas de contratos inteligentes. Los estudios muestran que, con una carga de trabajo de bajo conflicto, la TPS medida en las pruebas de referencia es de 3 a 5 veces superior a la ejecución serial tradicional. En cargas de trabajo de alto conflicto, teóricamente, la implementación de todas las medidas de optimización podría alcanzar incluso un incremento de 60 veces.
Esta solución de optimización de paralelismo multihilo de EVM mejora significativamente la capacidad de procesamiento de transacciones de EVM al asignar bibliotecas de estado temporales para cada transacción y ejecutarlas en paralelo en diferentes hilos. Al optimizar las operaciones de lectura y escritura e introducir un mecanismo de detección de conflictos, se logra una paralelización masiva de transacciones mientras se garantiza la coherencia del estado, resolviendo eficazmente el cuello de botella de rendimiento del modo de ejecución serial tradicional. Esto sienta una base importante para la futura expansión del ecosistema de Ethereum.
Las direcciones de investigación futuras pueden incluir la optimización adicional de la eficiencia de almacenamiento, la mejora de las soluciones de procesamiento en situaciones de alta colisión, así como la exploración del uso de GPU para la optimización. Estos avances proporcionarán un nuevo impulso para el desarrollo continuo de la Cadena de bloques.
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.
14 me gusta
Recompensa
14
7
Republicar
Compartir
Comentar
0/400
MEVVictimAlliance
· hace1h
¡La concurrencia, apúrate a solucionarlo, me está bloqueando!
Ver originalesResponder0
MelonField
· hace1h
Todavía están hablando de EVM, se ve mal.
Ver originalesResponder0
MetaDreamer
· hace1h
¿Aumento del rendimiento de 60 veces? gm vuelve a tener un pedido y se pone a trabajar.
Ver originalesResponder0
TestnetScholar
· hace1h
Optimiza esta tarjeta rápidamente.
Ver originalesResponder0
faded_wojak.eth
· hace1h
卡啦 并行化To the moon啊
Ver originalesResponder0
BugBountyHunter
· hace1h
¡Si te quedas atascado, debes hacerlo en paralelo e involucrarte en la competencia!
Ver originalesResponder0
DefiPlaybook
· hace2h
¿No está este cuello de botella esperando a ser aprovechado? Los Bots de carrera están extasiados.
Optimización paralela de EVM: la tecnología clave para mejorar el rendimiento de la Cadena de bloques en 60 veces
Optimización de la paralelización de EVM: clave para mejorar el rendimiento de la Cadena de bloques
EVM, como el motor de ejecución central de Ethereum, siempre ha utilizado un enfoque secuencial para procesar transacciones. Este método, aunque simple y fácil de mantener, ha mostrado cada vez más sus cuellos de botella en rendimiento con la expansión de la base de usuarios y los avances tecnológicos. Especialmente hoy en día, con la amplia aplicación de la tecnología Rollup, la ejecución secuencial de EVM se ha convertido en un factor limitante importante para el desarrollo de la red de segunda capa.
El Sequencer, como componente central de Layer2, asume todas las tareas de cálculo en forma de un solo servidor. Cuando otros módulos tienen suficiente eficiencia, la capacidad de procesamiento del Sequencer se convierte en el cuello de botella final. Algunos equipos han optimizado la capa DA y los módulos de lectura y escritura de datos, permitiendo que el Sequencer ejecute aproximadamente 2000 transferencias ERC-20 por segundo. Este número parece no ser bajo, pero ante transacciones más complejas, el TPS necesariamente disminuirá drásticamente. Por lo tanto, la paralelización del procesamiento de transacciones se convierte en una tendencia inevitable para el desarrollo futuro.
En la estructura del código de Ethereum, además de EVM, stateDB también es un componente central estrechamente relacionado con la ejecución de transacciones. Es responsable de gestionar el estado de las cuentas y el almacenamiento de datos de Ethereum. Cada vez que EVM ejecuta una transacción, cambia ciertos datos en stateDB, y estos cambios finalmente se reflejan en el árbol de estado global.
stateDB mantiene principalmente el estado de todas las cuentas de Ethereum, incluyendo cuentas normales y cuentas de contrato, almacenando el saldo de la cuenta, el código del contrato inteligente y otra información. Durante el proceso de ejecución de la transacción, stateDB lee y escribe los datos de la cuenta correspondiente, y después de que la ejecución finaliza, envía el nuevo estado a la base de datos subyacente para su almacenamiento permanente.
En el modo de ejecución secuencial tradicional, las transacciones dentro de un Bloquear se procesan una por una en orden. Cada transacción tiene una instancia de EVM independiente que ejecuta operaciones específicas, pero todas las transacciones comparten la misma stateDB. Durante el proceso de ejecución, el EVM necesita interactuar frecuentemente con la stateDB, leyendo y escribiendo datos relevantes.
El defecto de este modo de ejecución en serie es muy evidente: las transacciones deben esperar en una cola para ser ejecutadas. Si se encuentra con una transacción de contrato complejo que consume mucho tiempo, las transacciones posteriores solo pueden esperar forzosamente, sin poder aprovechar plenamente los recursos de hardware, lo que limita gravemente la eficiencia de procesamiento.
Para superar este cuello de botella, la industria ha propuesto un esquema de optimización de múltiples hilos paralelo para EVM. La idea central es abrir múltiples hilos para procesar varias transacciones al mismo tiempo, lo que aumenta considerablemente la eficiencia. Sin embargo, el principal desafío de la ejecución paralela es cómo manejar el problema de conflictos de estado.
Un enfoque de optimización paralela de EVM en un proyecto merece atención. Asignan una transacción y una base de datos de estado temporal (pending-stateDB) a cada hilo. Los pasos específicos son los siguientes:
Ejecución paralela de transacciones en múltiples hilos, donde los hilos no interfieren entre sí.
Cada hilo tiene una pending-stateDB independiente, y durante la ejecución de la transacción, no modifica directamente la stateDB global, sino que almacena temporalmente los cambios de estado en la pending-stateDB.
Una vez que se hayan ejecutado todas las transacciones en el bloque, el EVM sincronizará sucesivamente los cambios de estado en cada pending-stateDB al stateDB global.
El proyecto también ha optimizado las operaciones de lectura y escritura:
Al realizar una operación de lectura, EVM primero verifica el ReadSet del estado pendiente. Si hay datos necesarios, se leen directamente de pending-stateDB; de lo contrario, se leen del stateDB global del bloque anterior.
Las operaciones de escritura no se escriben directamente en el stateDB global, sino que primero se registran en el WriteSet del estado pendiente. Una vez completada la ejecución de la transacción, se intenta fusionar en el stateDB global a través de la detección de conflictos.
Para resolver el problema de conflictos de estado, el proyecto introdujo un mecanismo de detección de conflictos:
Durante el proceso de ejecución, se monitorean los ReadSet y WriteSet de diferentes transacciones; si varias transacciones leen y escriben el mismo elemento de estado, se considera un conflicto.
Marcar transacciones en conflicto como necesarias para reejecutar.
Una vez que se ejecutan todas las transacciones, los registros de cambios del estado múltiple de pending-stateDB se combinan en el stateDB global. Después de una combinación exitosa, el estado final se envía al árbol de estado global, generando una nueva raíz de estado.
La optimización del paralelismo multihilo ha mejorado significativamente el rendimiento, especialmente al manejar transacciones complejas de contratos inteligentes. Los estudios muestran que, con una carga de trabajo de bajo conflicto, la TPS medida en las pruebas de referencia es de 3 a 5 veces superior a la ejecución serial tradicional. En cargas de trabajo de alto conflicto, teóricamente, la implementación de todas las medidas de optimización podría alcanzar incluso un incremento de 60 veces.
Esta solución de optimización de paralelismo multihilo de EVM mejora significativamente la capacidad de procesamiento de transacciones de EVM al asignar bibliotecas de estado temporales para cada transacción y ejecutarlas en paralelo en diferentes hilos. Al optimizar las operaciones de lectura y escritura e introducir un mecanismo de detección de conflictos, se logra una paralelización masiva de transacciones mientras se garantiza la coherencia del estado, resolviendo eficazmente el cuello de botella de rendimiento del modo de ejecución serial tradicional. Esto sienta una base importante para la futura expansión del ecosistema de Ethereum.
Las direcciones de investigación futuras pueden incluir la optimización adicional de la eficiencia de almacenamiento, la mejora de las soluciones de procesamiento en situaciones de alta colisión, así como la exploración del uso de GPU para la optimización. Estos avances proporcionarán un nuevo impulso para el desarrollo continuo de la Cadena de bloques.