Como es bien sabido, EVM es el motor de ejecución central de Ethereum y el entorno de ejecución de contratos inteligentes. Como una red abierta que contiene una gran cantidad de nodos, las cadenas de bloques públicas enfrentan el desafío de lograr una ejecución consistente en dispositivos con diferencias de parámetros de hardware tan grandes. La tecnología de máquina virtual proporciona una posible solución a este problema, permitiendo que los contratos inteligentes se ejecuten de la misma manera en diferentes sistemas operativos y dispositivos, asegurando la consistencia de los resultados.
Los contratos inteligentes se compilan en código de bytes EVM antes de ser desplegados en la cadena. Al ejecutar un contrato, EVM lee este código de bytes secuencialmente, 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.
Tradicionalmente, el EVM maneja las transacciones de manera secuencial, donde todas las transacciones se colocan en una única cola y se ejecutan en un orden determinado. Este diseño es simple de mantener, pero a medida que la tecnología blockchain ha evolucionado y la base de usuarios se ha ampliado, las demandas sobre el TPS y el rendimiento han aumentado continuamente. Con la madurez de la tecnología Rollup, el cuello de botella de rendimiento del EVM en la ejecución secuencial se ha vuelto especialmente evidente 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 complementarios tienen suficiente eficiencia, el cuello de botella final dependerá de la eficiencia del secuenciador mismo, en cuyo caso la ejecución en serie se convertirá en un obstáculo importante. Por lo tanto, la paralelización del procesamiento de transacciones se convierte en una tendencia inevitable para el futuro.
Componente central de 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. Cada vez que se ejecuta una transacción, ciertos datos en stateDB cambian, y estos cambios se reflejan finalmente 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 contratos, almacenando datos como el saldo de la cuenta y el código del contrato inteligente. Durante el proceso de ejecución de la transacción, stateDB lee y escribe los datos de la cuenta correspondiente. Al finalizar la ejecución de la transacción, stateDB envía el nuevo estado a la base de datos subyacente para su persistencia.
En general, EVM es responsable de interpretar y ejecutar instrucciones de contratos inteligentes, cambiando el estado de la blockchain según los resultados de los cálculos, mientras que stateDB actúa como 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.
el proceso específico de ejecución en serie
Las transacciones de Ethereum se dividen en dos tipos: transferencias EOA y transacciones de contrato. Las transferencias EOA son el tipo de transacción más simple, es decir, la transferencia de ETH entre cuentas normales, que no involucra llamadas a contratos, con una velocidad de procesamiento rápida y tarifas de gas bajas.
El trading de contratos implica la invocación y ejecución de contratos inteligentes. Cuando EVM procesa 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 Uniswap, pueden tardar más de diez veces el tiempo de una transferencia EOA. Esto se debe a que los protocolos DeFi necesitan manejar complejas lógicas como 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 modo de ejecución secuencial, el proceso de colaboración entre EVM y stateDB es el siguiente:
Las transacciones dentro del bloque se procesan en orden, una por una, y cada transacción tiene una instancia independiente que ejecuta operaciones específicas.
Todas las transacciones comparten la misma base de datos de estado stateDB.
Durante el proceso de ejecución de la transacción, el EVM interactúa continuamente con el stateDB, lee los datos relevantes y escribe los datos modificados de vuelta en el stateDB.
Una vez que se han ejecutado todas las transacciones en el bloque, los datos en stateDB se envían al árbol de estado global, generando una nueva raíz de estado.
El cuello de botella de este modo de ejecución en serie es evidente: las transacciones deben ejecutarse en cola, y si hay una transacción de contrato inteligente que toma mucho tiempo, otras transacciones solo pueden esperar, lo que impide el uso completo de los recursos de hardware y limita considerablemente la eficiencia.
Solución de optimización de paralelismo multihilo de EVM
El modo de ejecución en paralelo puede abrir múltiples hilos para procesar varias transacciones simultáneamente, lo que puede aumentar la eficiencia varias veces, pero enfrenta problemas de conflicto de estado. Cuando varias transacciones declaran al mismo tiempo que desean reescribir los datos de una determinada cuenta, se produce un conflicto que requiere un manejo coordinado.
Principios de optimización en paralelo
Tomando como ejemplo el enfoque de optimización paralela del proyecto ZKRollup Reddio, sus principales características incluyen:
Ejecución de transacciones en paralelo con múltiples hilos: configura varios hilos para procesar diferentes transacciones simultáneamente, sin interferencia entre los hilos, lo que puede aumentar varias veces la velocidad de procesamiento de transacciones.
Asignar una base de datos de estado temporal para cada hilo: cada hilo tiene su propia base de datos de estado temporal (pending-stateDB). Durante la ejecución de la transacción, los resultados de los cambios de estado se registran temporalmente en la pending-stateDB, sin modificar directamente la stateDB global.
Sincronización de cambios de estado: Después de que se completen todas las transacciones dentro del bloque, se sincronizarán sucesivamente los resultados de los cambios de estado registrados en cada pending-stateDB en el stateDB global.
Reddio ha optimizado el manejo de las operaciones de lectura y escritura:
Operación de lectura: primero revisa el ReadSet del estado pendiente. Si existen los datos necesarios, se leen directamente de la base de datos del estado pendiente; de lo contrario, se leen los datos del estado histórico de la base de datos del estado global correspondiente al bloque anterior.
Operaciones de escritura: todas las operaciones de escritura se registran primero en el WriteSet del estado pendiente, y luego, tras completar la ejecución de la transacción, se intenta fusionar los resultados de los cambios de estado en la base de datos global stateDB mediante la detección de conflictos.
Para resolver el problema de conflictos de estado, Reddio ha introducido un mecanismo de detección de conflictos:
Detección de conflictos: Monitoreo de los 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: Las transacciones en conflicto se marcan como necesarias para ser reejecutadas.
Después de que se completan todas las transacciones, los registros de cambios en varios pending-stateDB se fusionan en el stateDB global. Tras la fusión exitosa, el estado final se envía al árbol de estados global, generando una nueva raíz de estado.
La optimización de la ejecución paralela multihilo ha mejorado significativamente el rendimiento, especialmente al manejar transacciones complejas de contratos inteligentes. La investigación muestra que, en cargas de trabajo de bajo conflicto, el TPS de las pruebas de referencia ha aumentado de 3 a 5 veces en comparación con la ejecución en serie 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 de Reddio mejora significativamente la capacidad de procesamiento de transacciones de EVM al asignar bibliotecas de estado temporales para cada transacción y ejecutar transacciones en paralelo en diferentes hilos. Al optimizar las operaciones de lectura y escritura e introducir un mecanismo de detección de conflictos, la cadena pública EVM puede lograr la paralelización masiva de transacciones mientras garantiza la consistencia del estado, resolviendo el cuello de botella de rendimiento del modelo de ejecución serial tradicional. Esto establece una base importante para el futuro desarrollo de Rollup de Ethereum.
En el futuro, se pueden discutir más a fondo los detalles de implementación de Reddio, incluyendo cómo optimizar aún más la eficiencia de almacenamiento, las soluciones de optimización en situaciones de alta conflictividad, y cómo aprovechar la GPU para la optimización, entre otros temas.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
9 me gusta
Recompensa
9
5
Compartir
Comentar
0/400
GasFeeCrybaby
· hace16h
¡Con gwei tan alto, hay que ir con todo!
Ver originalesResponder0
GateUser-cff9c776
· hace16h
on-chain炼丹呢这是
Ver originalesResponder0
RugPullAlertBot
· hace16h
¿Esto puede correr?
Ver originalesResponder0
NFTArtisanHQ
· hace16h
la disrupción del paradigma fr... la paralelización de reddio es pura poesía digital, para ser honesto
Ver originalesResponder0
BearMarketSurvivor
· hace16h
¿La concurrencia on-chain no nos da oportunidades para hacer trading?
Optimización de la paralelización EVM: Mejora de la eficiencia del procesamiento de transacciones con Reddio como ejemplo
El camino de la optimización paralela de EVM
Como es bien sabido, EVM es el motor de ejecución central de Ethereum y el entorno de ejecución de contratos inteligentes. Como una red abierta que contiene una gran cantidad de nodos, las cadenas de bloques públicas enfrentan el desafío de lograr una ejecución consistente en dispositivos con diferencias de parámetros de hardware tan grandes. La tecnología de máquina virtual proporciona una posible solución a este problema, permitiendo que los contratos inteligentes se ejecuten de la misma manera en diferentes sistemas operativos y dispositivos, asegurando la consistencia de los resultados.
Los contratos inteligentes se compilan en código de bytes EVM antes de ser desplegados en la cadena. Al ejecutar un contrato, EVM lee este código de bytes secuencialmente, 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.
Tradicionalmente, el EVM maneja las transacciones de manera secuencial, donde todas las transacciones se colocan en una única cola y se ejecutan en un orden determinado. Este diseño es simple de mantener, pero a medida que la tecnología blockchain ha evolucionado y la base de usuarios se ha ampliado, las demandas sobre el TPS y el rendimiento han aumentado continuamente. Con la madurez de la tecnología Rollup, el cuello de botella de rendimiento del EVM en la ejecución secuencial se ha vuelto especialmente evidente 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 complementarios tienen suficiente eficiencia, el cuello de botella final dependerá de la eficiencia del secuenciador mismo, en cuyo caso la ejecución en serie se convertirá en un obstáculo importante. Por lo tanto, la paralelización del procesamiento de transacciones se convierte en una tendencia inevitable para el futuro.
Componente central de 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. Cada vez que se ejecuta una transacción, ciertos datos en stateDB cambian, y estos cambios se reflejan finalmente 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 contratos, almacenando datos como el saldo de la cuenta y el código del contrato inteligente. Durante el proceso de ejecución de la transacción, stateDB lee y escribe los datos de la cuenta correspondiente. Al finalizar la ejecución de la transacción, stateDB envía el nuevo estado a la base de datos subyacente para su persistencia.
En general, EVM es responsable de interpretar y ejecutar instrucciones de contratos inteligentes, cambiando el estado de la blockchain según los resultados de los cálculos, mientras que stateDB actúa como 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.
el proceso específico de ejecución en serie
Las transacciones de Ethereum se dividen en dos tipos: transferencias EOA y transacciones de contrato. Las transferencias EOA son el tipo de transacción más simple, es decir, la transferencia de ETH entre cuentas normales, que no involucra llamadas a contratos, con una velocidad de procesamiento rápida y tarifas de gas bajas.
El trading de contratos implica la invocación y ejecución de contratos inteligentes. Cuando EVM procesa 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 Uniswap, pueden tardar más de diez veces el tiempo de una transferencia EOA. Esto se debe a que los protocolos DeFi necesitan manejar complejas lógicas como 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 modo de ejecución secuencial, el proceso de colaboración entre EVM y stateDB es el siguiente:
El cuello de botella de este modo de ejecución en serie es evidente: las transacciones deben ejecutarse en cola, y si hay una transacción de contrato inteligente que toma mucho tiempo, otras transacciones solo pueden esperar, lo que impide el uso completo de los recursos de hardware y limita considerablemente la eficiencia.
Solución de optimización de paralelismo multihilo de EVM
El modo de ejecución en paralelo puede abrir múltiples hilos para procesar varias transacciones simultáneamente, lo que puede aumentar la eficiencia varias veces, pero enfrenta problemas de conflicto de estado. Cuando varias transacciones declaran al mismo tiempo que desean reescribir los datos de una determinada cuenta, se produce un conflicto que requiere un manejo coordinado.
Principios de optimización en paralelo
Tomando como ejemplo el enfoque de optimización paralela del proyecto ZKRollup Reddio, sus principales características incluyen:
Ejecución de transacciones en paralelo con múltiples hilos: configura varios hilos para procesar diferentes transacciones simultáneamente, sin interferencia entre los hilos, lo que puede aumentar varias veces la velocidad de procesamiento de transacciones.
Asignar una base de datos de estado temporal para cada hilo: cada hilo tiene su propia base de datos de estado temporal (pending-stateDB). Durante la ejecución de la transacción, los resultados de los cambios de estado se registran temporalmente en la pending-stateDB, sin modificar directamente la stateDB global.
Sincronización de cambios de estado: Después de que se completen todas las transacciones dentro del bloque, se sincronizarán sucesivamente los resultados de los cambios de estado registrados en cada pending-stateDB en el stateDB global.
Reddio ha optimizado el manejo de las operaciones de lectura y escritura:
Operación de lectura: primero revisa el ReadSet del estado pendiente. Si existen los datos necesarios, se leen directamente de la base de datos del estado pendiente; de lo contrario, se leen los datos del estado histórico de la base de datos del estado global correspondiente al bloque anterior.
Operaciones de escritura: todas las operaciones de escritura se registran primero en el WriteSet del estado pendiente, y luego, tras completar la ejecución de la transacción, se intenta fusionar los resultados de los cambios de estado en la base de datos global stateDB mediante la detección de conflictos.
Para resolver el problema de conflictos de estado, Reddio ha introducido un mecanismo de detección de conflictos:
Detección de conflictos: Monitoreo de los 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: Las transacciones en conflicto se marcan como necesarias para ser reejecutadas.
Después de que se completan todas las transacciones, los registros de cambios en varios pending-stateDB se fusionan en el stateDB global. Tras la fusión exitosa, el estado final se envía al árbol de estados global, generando una nueva raíz de estado.
La optimización de la ejecución paralela multihilo ha mejorado significativamente el rendimiento, especialmente al manejar transacciones complejas de contratos inteligentes. La investigación muestra que, en cargas de trabajo de bajo conflicto, el TPS de las pruebas de referencia ha aumentado de 3 a 5 veces en comparación con la ejecución en serie 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 de Reddio mejora significativamente la capacidad de procesamiento de transacciones de EVM al asignar bibliotecas de estado temporales para cada transacción y ejecutar transacciones en paralelo en diferentes hilos. Al optimizar las operaciones de lectura y escritura e introducir un mecanismo de detección de conflictos, la cadena pública EVM puede lograr la paralelización masiva de transacciones mientras garantiza la consistencia del estado, resolviendo el cuello de botella de rendimiento del modelo de ejecución serial tradicional. Esto establece una base importante para el futuro desarrollo de Rollup de Ethereum.
En el futuro, se pueden discutir más a fondo los detalles de implementación de Reddio, incluyendo cómo optimizar aún más la eficiencia de almacenamiento, las soluciones de optimización en situaciones de alta conflictividad, y cómo aprovechar la GPU para la optimización, entre otros temas.