Imagínate esto: estás en una cocina ocupada donde los chefs deben esperar a que uno termine de cortar verduras antes de que el siguiente pueda empezar a hornear papas. Suena frustrantemente lento e ineficiente, ¿verdad? Eso es lo que es la ejecución síncrona en computación y blockchain: una tarea debe terminar antes de que se pueda comenzar la siguiente. Ahora, imagina una cocina bien coordinada donde cada chef trabaja en diferentes partes de varios platos al mismo tiempo, preparando ingredientes, cocinando y emplatando todo a la vez. Eso es la ejecución asíncrona: las tareas se ejecutan simultáneamente, creando un flujo de trabajo más eficiente y rápido.

En la encrucijada de la evolución de la cadena de bloques, la composabilidad sincrónica se ha convertido en una palabra de moda porque parece ofrecer una solución para unir las capas 2 fragmentadas en la red Ethereum. Este enfoque aborda la desastrosa experiencia de usuario y desarrollo, donde incluso una simple transferencia entre capas 2 podría costar un dólar y llevar hasta 7 días.La participación de Vitaliken estos debates se destaca que la sincronía universal no es necesariamente un requisito para resolver estos problemas. Estamos de acuerdo en que la ejecución de la traducción efectiva no tiene que implicar sincronía, y hay costos reales para construir y mantener una infraestructura sincrónica. Creemos que no es una elección binaria entre todo siendo sincrónico o asincrónico. Ambos pueden coexistir de manera ad hoc, con una probable tendencia hacia lo último.

1. Descomponibles Asincrónicos

En la búsqueda de un rendimiento escalable en la tecnología blockchain, la ejecución en paralelo de contratos inteligentes individuales ha generado una atención significativa. Convencionalmente, el rendimiento de cada contrato inteligente ha estado limitado por las capacidades de una sola máquina virtual (EVM), incluso con el advenimiento de sistemas multi-cadena o de capa 2. Las máquinas virtuales paralelas ofrecen una solución prometedora, permitiendo que las transacciones de un solo contrato inteligente se ejecuten de manera concurrente, aprovechando así más núcleos de CPU para un mejor rendimiento.

Parallel Relay-Execution Distributed Architecture (PREDA) es un modelo de programación distribuido, funcional, orientado al ámbito y de alto nivel diseñado para contratos inteligentes generales inherentemente paralelizados en sistemas de blockchain multi-EVM distribuidos. Desde una perspectiva del sistema, PREDA hace que los EVM paralelos sean descomponibles y asíncronos, lo que permite la total paralelización de una función de contrato y maximiza la concurrencia de un conjunto de transacciones. Esto garantiza que todas las instancias de EVM se puedan utilizar al máximo, logrando un rendimiento y una escalabilidad óptimos.

Antes de adentrarnos en los detalles más específicos, primero aclaremos a qué se refieren varios términos clave en este artículo:

Tx1= Transacción 1

Tx2= Transacción 2

Suponemos que,

La ejecución de Tx1 necesita cambiar el estado A, el estado B, el estado C

La ejecución de Tx2 necesita cambiar el estado A, el estado D, el estado E

Los métodos de paralelización de vanguardia para las EVM¹, como los implementados por Sei, Aptos y Sui, intentan ejecutar todas las etapas en cada transacción de manera sincrónica. Imagina hacer zoom en una sola escena de transacción, en estos sistemas una transacción se ejecuta dentro de una altura de bloque, independientemente de la naturaleza de las dependencias de datos dispersos (es decir, accediendo a diferentes piezas de estados de contrato). Como resultado, si alguna etapa de los estados de contrato accesados son compartidos o actualizados entre dos transacciones, se identifican como conflictos de lectura-escritura o escritura-escritura y no se pueden ejecutar en paralelo, lo que dificulta el rendimiento general y la escalabilidad del sistema. Esta situación empeora significativamente cuando la actividad en cadena de repente se dispara.

PREDA adopta un modelo de ejecución de contrato inteligente que implementa una descomposición asincrónica, donde los pasos de una transacción se descomponen según sus dependencias de acceso a datos, permitiendo que los pasos se ejecuten de forma asíncrona. El modelo de ejecución de PREDA resulta en una mayor eficiencia y escalabilidad teóricamente infinita. Profundizaremos más en cómo PREDA logra esto y demostraremos resultados experimentales para respaldar esta afirmación.

2. Evaluación del rendimiento

Las transacciones de transferencia de tokens ETH históricas se reproducen para evaluar Sei (V2), Aptos, Sui y PREDA, por rendimiento y escalabilidad. Tenga en cuenta que nuestra evaluación emplea transacciones reales de transferencia de tokens ETH históricas en lugar de crear un conjunto de transacciones entre pares de direcciones aleatorias. Las transacciones aleatorias producirán un resultado experimental excesivamente superior al rendimiento en casos reales, ya que las transacciones del mundo real involucran direcciones que están relacionadas de una forma u otra, lo que introduce una gran cantidad de dependencias de datos.

Las configuraciones experimentales son las siguientes:

La comparación en la Figura 1 destaca la necesidad de adoptar el modelo de programación PREDA para lograr mejoras significativas en el rendimiento. PREDA demuestra un TPS 3,3X — 28,2X mayor que Aptos para transacciones de transferencia históricas reales en la red Ethereum.

Dado que estos sistemas se implementan en diferentes lenguajes (incluyendo Go, Rust y C++) y diferentes máquinas virtuales, evaluamos la escalabilidad de diferentes sistemas en función de la aceleración relativa sobre la base de utilizar un solo EVM, para excluir el impacto de las implementaciones del sistema diferentes.

Figura 1. Los números absolutos de rendimiento en TPS de contratos inteligentes de transferencia de tokens equivalentes ejecutados en Sei, Aptos, Sui y PREDA

Figura 2. Mejoras relativas de velocidad para Aptos, Sui, Sei y PREDA sobre sus propias líneas de base

3. El Modelo de Programación

Para facilitar la comprensión de PREDA para cualquier persona familiarizada con EVM paralelo, existen dos tipos típicos de mecanismos de paralelización en los sistemas de blockchain EVM paralelos de hoy¹.

• La paralelización optimista, que incluye Aptos, Sei (V2) y Monad, ignora las dependencias de estado entre transacciones, ejecuta y valida transacciones concurrentemente, y retrocede una transacción para volver a ejecutarla en caso de conflicto.
• La paralelización pesimista, que incluye Solana (Sealevel), Sui y Sei (V1), verifica las dependencias de estado previo de cada transacción antes de la ejecución, analiza sus dependencias de estado y ejecuta simultáneamente solo aquellas transacciones que no tienen conflictos.

Ambos métodos siguen la Arquitectura de Compartición Total y tratan una transacción como un todo en el control de concurrencia; todos los pasos (por ejemplo, acceder a diferentes estados de contrato) no son descomponibles y deben ejecutarse de forma sincrónica. El modelo PREDA propone @devteam_48518/crystality-el-modelo-evm-paralelo-implementando-la-arquitectura-de-no-compartir-nada-8d82fc0a836a">Arquitectura de no compartir nada para romper las dependencias de estado y garantizar que las diferentes instancias de EVM nunca accedan a la misma parte del estado de contrato, evitando conflictos de escritura por completo.

En su núcleo, PREDA introduce los Alcances de Contratos Programables para descomponer el estado del contrato en piezas no superpuestas y paralelizables con granularidad fina, y el Relevo Funcional Asíncrono para describir el interruptor de flujo de ejecución en diferentes EVMs.

Para explicar aún más lo que significan estos conceptos, en PREDA, una función de contrato se descompone en múltiples pasos ordenados, cada uno dependiendo de una sola pieza paralelizable del estado sin conflictos. Una transacción iniciada por el usuario se dirige primero a un EVM que mantiene los estados de la dirección del usuario de manera determinista, como usando un método de mapeo de dirección de usuario a EVM. Durante la ejecución de la transacción, el flujo de ejecución puede cambiar de un EVM a otro que posee los estados de contrato deseados emitiendo una transacción de retransmisión. De esta manera, PREDA mantiene los datos estacionarios mientras mueve el flujo de ejecución alrededor de los EVM según las dependencias de los datos.

En cada EVM, las transacciones iniciadas por el usuario y las transacciones de retransmisión se ordenan y ejecutan secuencialmente, mientras que las transacciones en diferentes EVM se ejecutan simultáneamente porque no hay dependencias de datos entre las EVM. Este mecanismo evita la reejecución relacionada con conflictos en métodos optimistas basados en paralelización y la necesidad de análisis de dependencias de estado en tiempo de ejecución y sobrecarga de bloqueo/desbloqueo en enfoques pesimistas basados en paralelización. Por lo tanto, PREDA proporciona una arquitectura paralela y de nada compartido para los sistemas de cadena de bloques, que difiere de la arquitectura secuencial y de todo compartido tanto en Solidity como en Move, que puede incurrir en una sobrecarga significativa de control de concurrencia.

4. El Idioma

Implementamos el modelo de programación PREDA como un lenguaje similar a Algo, C/C++ y Javascript. A continuación se muestra una función simplificada de transferencia de tokens en Solidity y en el lenguaje PREDA.

El código Solidity en la Figura (a) presenta un estado de contrato (balances) que representa los saldos de direcciones y una función de transferencia para transferir una cantidad especificada de tokens del remitente de la transacción (msg.sender) a un receptor (payee).

En la implementación PREDA mostrada en la Figura (b), la palabra clave @addressdefine ámbitos de contrato programables, donde los estados de contrato pertenecientes a una variable de contrato (saldo) están particionados por dirección, y dispersos y gestionados por EVMs. La palabra clave relay identifica un relay funcional asincrónico.

Hay tres partes en la implementación de PREDA. En la parte (1), la palabra clave @addressdefine los saldos de los usuarios, proporcionando una descripción de estado detallada y separable. La variable de ámbito de dirección balance tiene una instancia única para cada dirección de usuario. Las instancias de diferentes direcciones de usuario son accedidas y mantenidas por diferentes EVMs sin superposición. La función de transferencia se define en el mismo ámbito de dirección en la parte (2), invocada proporcionando la dirección del pagador como el ámbito objetivo al inicializar una transacción de transferencia por un usuario. En la parte (3), para proceder con el depósito al beneficiario después de una retirada exitosa, se inicia un relé con la dirección del beneficiario como ámbito objetivo, agregando fondos al saldo del beneficiario y ejecutado por un EVM que hospeda la instancia de saldo de la dirección del beneficiario.

El flujo de ejecución de una transacción de transferencia de tokens en PREDA

La figura anterior muestra el flujo de ejecución de una transacción de transferencia de tokens en el sistema EVM paralelo de PREDA. Bob inicia una transacción para llamar a la función de transferencia, que será dirigida al EVM que tiene el saldo de Bob y se ejecutará el retiro allí. Después de eso, se emite una transacción de relé y se dirige al EVM que tiene el saldo de Alice y se ejecuta el depósito. La paralelización ocurre de dos formas:

1. Entre transacciones iniciadas por el usuario: dado que los estados particionados por dirección no se superponen, las transacciones iniciadas por el usuario se pueden ejecutar simultáneamente sin conflictos. Por ejemplo, en el contrato de transferencia de tokens que actualiza el estado del pagador por dirección, diferentes transacciones iniciadas por el usuario se pueden paralelizar en EVMs.
2. Con transacciones de relé: en un escenario donde Bob transfiere tokens a Alice y Carol, la transacción de relé para el depósito a Alice (desde la transferencia de Bob a Alice) se puede ejecutar simultáneamente con la transacción iniciada por el usuario para la retirada de Bob (en la transferencia de Bob a Carol) y el depósito a Carol. Solo con la descomposición del modelo PREDA se puede exponer la paralelización inherente en un contrato inteligente al sistema de blockchain subyacente, permitiendo que las transacciones iniciadas por el usuario y las de relé se procesen de manera pipelined, facilitando la ejecución paralela.

Siguiente y más allá

PREDA marca un avance importante en el rendimiento de la cadena de bloques y, lo que es más importante, en la escalabilidad. Al implementar la descomposición asincrónica, permite el procesamiento eficiente de transacciones sin los cuellos de botella de los modelos convencionales de paralelización síncrona. Este enfoque descompone las transacciones en microtransacciones según las dependencias de datos, lo que permite cambios de estado concurrentes y evita por completo los conflictos de escritura.

La generalidad de PREDA se extiende más allá de usar @address para particionar los estados del contrato por dirección. Permite tipos de partición personalizados con palabras clave como @type, donde el tipo puede ser cualquier nombre de tipo elemental de Solidity como @uint. Además, PREDA admite estados de contrato sin particionar con @global, asegurando que cada EVM mantenga valores consistentes para dichos estados. Esta flexibilidad en la partición de estados mejora la adaptabilidad y efectividad del modelo en diversos contratos inteligentes.

Nuestros experimentos demuestran que PREDA supera significativamente a otros métodos de paralelización, logrando mayor rendimiento y escalabilidad. Los próximos artículos del equipo de PREDA profundizarán en nuestros hallazgos, ofreciendo comparaciones más completas con varios tipos de contratos inteligentes y análisis detallados del modelo y lenguaje de programación de PREDA. Manténgase atento a estas exploraciones detalladas.

Descargo de responsabilidad:

1. Este artículo es una reimpresión de [Medio]. Los derechos de autor pertenecen al autor original, [PREDA Parallel VMs]. Si tienes alguna objeción con respecto a esta publicación, por favor contacta agate Aprender EquipoEl equipo abordará sus inquietudes de manera pronta de acuerdo con los procedimientos correspondientes.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen asesoramiento de inversión.
3. El equipo de gate Learn tradujo el artículo a otros idiomas. Está prohibido copiar, distribuir o plagiar los artículos traducidos, a menos que se mencione.