---
id: 2
title: "Ejecución paralela multi-motor de Bitroot: planificación, particionado y la superficie de conflictos"
slug: bitroot-evm
date: 2026/08/07
summary: Un análisis profundo de la ejecución paralela multi-motor: cómo los motores comparten transacciones, cómo se particiona el estado para el acceso, cómo el control de concurrencia optimista y la detección de conflictos en tres etapas limitan la reejecución, y cómo leer la aceleración frente a la tasa de conflicto en condiciones de testnet.
keywords: ejecución paralela multi-motor,EVM,particionado de estado,detección de conflictos,Bitroot
heroImage: /cms-media/file/4In%20depth%20analysis%20of%20Bitroot.jpg
---

El cuello de botella de la EVM de un solo hilo no es «Solidity es lento»; es la semántica de ejecución serial y la falta de un lugar donde colocar la contención de bloqueos sobre el estado compartido. El paralelismo multi-motor es una cuestión de ingeniería: cómo repartir las transacciones de un bloque entre contextos de ejecución sin descartar el bloque entero ante un conflicto. Rutas de la industria: [Tres caminos hacia la ejecución paralela](/es/blog/parallel-execution-approaches). Este artículo se centra en el diseño multi-motor del lado de Bitroot. Esqueleto teórico: [Introducción al OCC](/es/blog/optimistic-concurrency-control-intro); aquí no se repite la historia de las cuatro fases de las bases de datos.

## Objetivo de diseño: paralelo, pero reproducible

Los diseños multi-motor suelen insistir en:

- contextos de ejecución relativamente independientes por motor, que reducen los bloqueos globales;
- estado particionado por cuenta o por slot de almacenamiento, para que los motores prefieran los fragmentos locales y recorten la sincronización entre motores;
- planificadores que preanalizan y agrupan en lotes, manteniendo las transacciones relacionadas en el mismo motor o lote para reducir el ida y vuelta;
- confirmaciones finales equivalentes a la ejecución serial bajo el orden del consenso (reproducción determinista).

Cómo el consenso emite el orden con rapidez: [Pipeline BFT y desacople de la ejecución](/es/blog/bitroot-pipeline-bft). Supuestos optimistas y reversión: [Paralelización optimista](/es/blog/bitrootevm-). Mapa de arquitectura: [Panorama de la arquitectura de EVM paralela](/es/blog/bitrootevm).

## Planificación: no es rociar transacciones por turnos

El reparto ingenuo por turnos (round-robin) distribuye las transacciones de manera uniforme hasta que aparece un contrato caliente y los motores empiezan a pelear. Los planificadores mejores estiman:

- la complejidad y la magnitud del gas (de forma gruesa);
- las particiones de estado que probablemente se tocarán;
- la prioridad y la afinidad de lote (transacciones relacionadas juntas para recortar la sincronización entre motores).

La planificación también cuesta: un preanálisis demasiado grueso agrupa mal; un análisis demasiado fino se convierte en un cuello de botella serial. Un compromiso común es «heurísticas estáticas + monitoreo en tiempo de ejecución»: agrupar de forma optimista y luego corregir con la detección de conflictos. Por qué los hotspots de DeFi perforan el paralelismo: [Hotspots de conflicto y cargas de trabajo](/es/blog/parallel-evm-workload-hotspots).

## Particionado del estado: el siguiente muro tras la ejecución paralela

Una vez que la ejecución se paraleliza, un único árbol de estado y la memoria de una sola máquina siguen limitando el rendimiento. El particionado reduce el espacio de estado: paralelismo dentro de un fragmento; mensajes explícitos o confirmación asíncrona entre fragmentos. Los objetos grandes caben en almacenamiento fuera de cadena con hashes en cadena para aliviar la presión sobre los nodos completos. El particionado no es gratis: la atomicidad entre fragmentos y la carga mental del desarrollador aumentan; conviene escribir esas reglas en el protocolo y no dejar las aplicaciones a la suerte.

El DeFi componible entre fragmentos suele ser la prueba de estrés: las rutas que tocan muchos pools acumulan conflictos de escritura con la latencia del protocolo entre fragmentos. Cómo el producto admite ese límite: [Posicionamiento de Bitroot](/es/blog/bitroot-positioning).

## Detección de conflictos: reducir el radio de la explosión

El precio del paralelismo optimista es el conflicto. Los materiales de Bitroot insisten en la detección en tres etapas:

1. **Antes de la ejecución**: heurísticas de dependencias y de lectura/escritura para dejar los conflictos evidentes fuera de la misma ventana paralela.
2. **Durante la ejecución**: monitoreo de versiones o de conjuntos de lectura/escritura para abortar antes las rutas inválidas.
3. **Después de la ejecución**: comprobaciones de consistencia de la raíz de estado para atrapar omisiones y errores de implementación.

El objetivo no es el conflicto cero, sino la reejecución selectiva cuando hay conflictos. La planificación colaborativa al estilo Block-STM de Aptos pertenece a la misma familia optimista, con detalles de implementación distintos: no conviene comparar de forma cruzada el TPS bruto de testnet entre proyectos.

## Cómo leer las curvas de «cantidad de motores ↔ TPS»

En las pruebas, agregar motores suele acelerar de forma casi lineal al principio y luego curvarse a medida que sube la tasa de conflicto. Las cifras públicas de testnet han citado miles de TPS con pocos motores y picos de decenas de miles con más, además de confirmaciones por debajo del segundo en configuraciones declaradas; todo depende del hardware, la mezcla de contratos y los supuestos de conflicto. Son observaciones de ingeniería, no SLA de mainnet ni promesas de rendimiento financiero. Conviene leer en conjunto el paralelismo efectivo, la tasa de conflicto, la proporción de reejecución y los percentiles de latencia; glosario: [Glosario de métricas de rendimiento](/es/blog/performance-metrics-glossary).

Que el multi-motor siga siendo transparente para los contratos existentes depende de la compatibilidad con EVM (bytecode, precompilados, herramientas); véase [Qué significa la compatibilidad con EVM](/es/blog/evm-compatibility-explained). Cómo el hardware y la geografía de los validadores pueden recuperar las ganancias del paralelismo: [Descentralización frente a rendimiento](/es/blog/decentralization-performance-tradeoff).

## Mantener el ritmo del consenso

Por muy rápido que sea el multi-motor, consume el orden del consenso. Si la ejecución se retrasa de forma crónica respecto de la producción de bloques, las vistas de estado sin confirmar se acumulan y las aplicaciones perciben que «los bloques son rápidos, pero las transacciones dependientes y las consultas siguen lentas». Las divulgaciones deberían mostrar el retraso de ejecución y los percentiles de confirmación, no solo los picos de los motores. Lado Pipeline: [Pipeline BFT y desacople de la ejecución](/es/blog/bitroot-pipeline-bft); posicionamiento: [Posicionamiento de Bitroot](/es/blog/bitroot-positioning).

Para los desarrolladores de aplicaciones, el multi-motor debería seguir siendo transparente: no se requiere sintaxis de Solidity para «declarar paralelismo». Lo que sí debe cambiar es la disposición del estado y los patrones de interacción: menos contadores globales únicos, menos usuarios escribiendo el mismo slot compartido. De lo contrario, los motores extra solo se quedan en bucle ocupado reejecutando. Compatibilidad: [Qué significa la compatibilidad con EVM](/es/blog/evm-compatibility-explained); público: [Quién debería leer sobre la EVM paralela](/es/blog/who-should-read-parallel-evm).

## Cachés, precarga y el impuesto de comunicación entre motores

Más allá de la cantidad de motores, las cachés por capas y la precarga de estado deciden si los motores trabajan de verdad. Una alta tasa de aciertos en el fragmento local acerca el paralelismo al ancho de CPU; las lecturas frecuentes de slots remotos aplanan la aceleración bajo el impuesto de comunicación. Los planificadores que solo miran el gas, y no la afinidad de partición, generan tráfico entre motores de forma sistemática.

Conviene monitorear la proporción de lecturas y escrituras entre motores, los recuentos de conflictos de versión y la profundidad de cola entre fragmentos. Esas métricas reflejan la capacidad real mejor que la cantidad de motores por sí sola. Tras el desacople del consenso, una ejecución lenta que se pone al día se manifiesta como una brecha mayor entre la confirmación y la raíz de estado; el usuario igual siente que «la cadena se puso más lenta». Panorama: [Panorama de la arquitectura de EVM paralela](/es/blog/bitrootevm).

## Efectos visibles para los autores de contratos

El multi-motor debería ser habitualmente transparente para quienes escriben Solidity: desplegar sin reescribir. Los efectos indirectos permanecen: los supuestos sobre el tiempo exacto dentro de un bloque o sobre que «las transacciones posteriores del mismo bloque siempre ven las escrituras anteriores» son más frágiles bajo ventanas especulativas; conviene apoyarse en límites de transacción y eventos explícitos, no en coincidencias no documentadas del planificador.

Las herramientas deben explicar las rutas de reejecución en las trazas, los perfiles de gas y los depuradores; de lo contrario, no se pueden reconstruir los incidentes. Rutas de lectura: [Quién debería leer sobre la EVM paralela](/es/blog/who-should-read-parallel-evm). Compatibilidad: [Qué significa la compatibilidad con EVM](/es/blog/evm-compatibility-explained).

Juzgue un diseño multi-motor por si las aceleraciones son explicables dada una curva de tasa de conflicto, si la reejecución es observable y si la semántica de los contratos heredados sigue siendo compatible. Esas tres cosas hacen una EVM paralela de ingeniería, no un intérprete multihilo de demostración.

## Observabilidad: sin métricas no hay paralelismo

El multi-motor en producción necesita utilización por motor, tasas de mensajes entre fragmentos, aciertos de conflicto por etapa, proporción de reejecución y tiempo desde el orden del consenso hasta la raíz de estado. Sin esas curvas, operaciones solo ve «cayó el TPS» y no puede distinguir planificación, contratos calientes o E/S de estado. Trate la observabilidad como parte de la funcionalidad, no como un adorno de panel posterior al lanzamiento.

Planificación, particionado y detección de conflictos deben leerse en conjunto: más motores sin observabilidad solo repiten los mismos fallos más rápido. Publicar las curvas de tasa de conflicto es la honestidad mínima hacia los desarrolladores y los validadores.

Al publicar cifras de testnet, etiquete la cantidad de motores, la mezcla de carga y la tasa de conflicto, y aclare que no son promesas de mainnet ni asesoramiento de inversión.

## Conclusión

El paralelismo multi-motor convierte «¿podemos ejecutar la EVM en muchos núcleos?» en planificación, particionado y control de conflictos. Amplifica el rendimiento en cargas con pocos conflictos y particionables; en los hotspots de pools compartidos de los AMM, más motores igual colapsan hacia lo serial: eso es un problema de la carga de trabajo, no algo que otra frase de marketing elimine.

## Lecturas relacionadas

- [Paralelización optimista](/es/blog/bitrootevm-)
- [Pipeline BFT y desacople de la ejecución](/es/blog/bitroot-pipeline-bft)
- [Hotspots de conflicto y cargas de trabajo](/es/blog/parallel-evm-workload-hotspots)