La ejecución paralela suena a «enciende más núcleos y el rendimiento sube». Para cargas con pocos conflictos, esa intuición es más o menos correcta: las transacciones que nunca tocan los mismos slots de estado pueden ser consumidas por distintos motores de ejecución a la vez, y la utilización de los múltiples núcleos sube. Pero el tráfico que de verdad congestiona las cadenas públicas rara vez son transferencias limpias entre pares. Son llamadas a contratos que leen y escriben repetidamente las mismas cuentas o slots de almacenamiento calientes. Entonces el paralelismo ya no está limitado por la cantidad de CPU, sino por la tasa de conflicto.
Una vez que se ve eso, se puede leer correctamente cualquier cifra de rendimiento de una «EVM paralela»: el mismo motor puede variar un orden de magnitud entre cargas de trabajo.
Conflicto bajo frente a conflicto alto: dos juegos distintos
Una carga de conflicto bajo se parece a muchas transferencias simples sin relación, movimientos entre tenedores de NFT independientes o consultas de solo lectura contra instancias de contrato distintas. Los conjuntos de lectura/escritura apenas se solapan, así que el paralelismo optimista puede acercarse a una «aceleración ideal»: N motores absorben casi N veces el trabajo sin conflicto, menos un costo fijo de planificación y verificación de versiones.
La carga de conflicto alto es lo contrario. El mismo par de un AMM, el mismo índice de intereses de un préstamo o el mismo contador de acuñación de NFT empaquetan muchas transacciones en un conjunto de estado diminuto. La ejecución optimista igual avanza en paralelo, pero la validación descubre conflictos de versión y muchas transacciones deben rehacerse en orden serial. Los motores parecen ocupados mientras el rendimiento efectivo colapsa hacia niveles de un solo hilo, más la sobrecarga de reversión y reejecución.
Así que «¿es rápida la EVM paralela?» no es una pregunta de sí o no. Es «¿cuánto más rápida, bajo qué distribución de conflictos?».
Por qué el AMM, los préstamos y las acuñaciones de NFT dañan el rendimiento
Los creadores de mercado automatizados concentran la liquidez y el precio en unos pocos slots de almacenamiento del contrato del pool. Varios swaps en el mismo bloque suelen leer y escribir los mismos slots de reserve o de precio, así que el conflicto es estructural. Aunque las direcciones de usuario difieran, los hotspots del lado del contrato bastan para aplanar el paralelismo.
Los préstamos son similares: los índices de interés, los totales globales de préstamo y los parámetros compartidos de liquidación se vuelven puntos de encuentro entre usuarios. Una transacción de «el usuario A deposita» puede compartir variables globales con el préstamo del usuario B y la liquidación del usuario C.
La acuñación de NFT es más extrema: los IDs secuenciales, los contadores de suministro y los bitmaps de lista de permitidos suelen ser un único punto de escritura bajo contención de corta vida. Las corridas históricas de acuñación en Ethereum empujaron las subastas de gas a rangos absurdos no solo porque «apareció mucha gente», sino porque la capa de ejecución no podía dividir esas escrituras tan acopladas.
Granularidad de los conjuntos de lectura/escritura: la perilla oculta de la tasa de conflicto
El paralelismo optimista usa los conjuntos de lectura/escritura para decidir si dos transacciones están libres de conflicto. Los conjuntos pueden ser tan gruesos como el nivel de cuenta o tan finos como cada slot de almacenamiento individual.
- Los conjuntos más gruesos sobreinforman conflictos: dos transacciones que tocan slots distintos del mismo contrato se serializan igual.
- Los conjuntos más finos elevan el costo de análisis y de gestión de versiones: el grafo de dependencias se fragmenta y los metadatos crecen, pero el paralelismo real también crece.
La ingeniería suele equilibrar heurísticas a nivel de cuenta y precisión a nivel de slot, con análisis estático de dependencias antes de la ejecución, vigilancia de versiones durante la ejecución y una comprobación de la raíz de estado después (véase Introducción al control de concurrencia optimista (OCC)). Para los desarrolladores de aplicaciones la implicación es concreta: repartir el estado no relacionado entre slots, reducir los contadores globales y evitar una única ruta caliente de totalSupply suele mejorar la experiencia de confirmación más que cambiar de cadena.
Cómo se degrada el TPS pico en los hotspots
Los benchmarks prefieren cargas sintéticas sin conflicto porque las curvas se ven bien. Los bloques reales son mixtos: algunas transferencias se paralelizan; algunas llamadas DeFi se atascan en hotspots. El rendimiento efectivo queda limitado aproximadamente por (ilustrativo, no una fórmula exacta):
rendimiento efectivo ≈ ganancia paralela sobre la porción sin conflicto + rendimiento casi serial sobre la porción en conflicto − costo de reversión/reejecución.
A medida que sube la porción en conflicto, los dos últimos términos dominan. Eso produce un desajuste común entre marketing e ingeniería: los materiales citan el «TPS pico bajo carga ideal», mientras que los usuarios en el día de acuñación o durante mercados volátiles sienten confirmaciones más lentas y más reintentos. La divulgación honesta muestra cifras tanto de conflicto bajo como de conflicto alto, declarando hardware, versión del cliente y mezcla de transacciones (véase Glosario de métricas de rendimiento).
Las cadenas de EVM paralela optimista que deciden enfrentar el DeFi componible, en lugar de optimizar solo los benchmarks de transferencias, hacen de la calidad de la detección de conflictos y de la agrupación dinámica la diferencia entre el rendimiento del cartel y el rendimiento visible para el usuario.
Implicaciones prácticas para el diseño de contratos y protocolos
- Encontrar los slots calientes: mapear las escrituras de alta frecuencia durante las auditorías; los contadores globales, los pools de liquidez únicos y los bits de configuración compartidos son los principales sospechosos.
- Dividir el estado: aislar las escrituras por usuario, pool o fragmento siempre que sea posible, en lugar de canalizarlas hacia un solo slot.
- Abandonar los supuestos de orden implícito: la lógica que depende del «orden implícito dentro del mismo bloque» es más frágil bajo paralelismo optimista; codifique el orden de forma explícita o haga el diseño tolerante a conflictos.
- Interpretar los benchmarks por tasa de conflicto: cuando vea una cifra de TPS, pregunte primero por la mezcla de transacciones; un pico sin distribución de conflictos tiene un valor de referencia limitado.
Cierre: el paralelismo no es gratis
La EVM paralela usa varios núcleos solo cuando la carga de trabajo contiene suficientes transacciones sin conflicto. Los contratos calientes no desaparecen porque cambie el motor de ejecución; trasladan el cuello de botella de «intérprete de un solo hilo» a «detección de conflictos y reejecución». Explicar eso es más útil que otro discurso de ascensor: le dice a los desarrolladores si deben cambiar la disposición del almacenamiento, y le dice a los lectores cómo dudar del próximo cartel de rendimiento.
Lecturas relacionadas
- Anterior: Descentralización frente a rendimiento: umbrales de validadores, hardware y geografía
- Relacionado: Tres caminos hacia la ejecución paralela: determinista, optimista y modelos de objetos
- Relacionado: Introducción al control de concurrencia optimista (OCC): una vista de bases de datos de la ejecución en cadena
- Relacionado: Glosario de métricas de rendimiento: TPS, BPS, latencia de confirmación, finalidad y tasa de conflicto