El estilo de comunicación fallido más común de los L1 de alto rendimiento es el cartel de TPS. Lo que ayuda es responder tres preguntas: quién decide el orden de las transacciones, cómo se paralelizan las transiciones de estado y cómo crece el tamaño del estado. Este artículo es un mapa de la EVM paralela de Bitroot, no una carrera de parámetros. Los mecanismos más finos viven en los textos de Pipeline BFT, multi-motor y paralelismo optimista; los puntos teóricos remiten al manual de OCC y al mapa de escalabilidad, para que este panorama no duplique esos ensayos.
Dónde empieza el problema
Las EVM clásicas ejecutan las transacciones una por una dentro de un bloque: la corrección es fácil de razonar; el rendimiento queda limitado por la semántica serial de un solo núcleo. En el mapa de escalabilidad, la ejecución paralela es solo una celda entre los rollups, el sharding y más; véase Mapear la escalabilidad de la cadena de bloques y El cuello de botella de la EVM de un solo hilo. La elección de Bitroot: mantener la compatibilidad total con EVM, tomar el camino del paralelismo optimista y desacoplar el consenso de la ejecución, sin obligar a los desarrolladores a predeclarar listas de cuentas.
Tres capas en concierto, no tres calcomanías
| Capa | Enfoque del mecanismo | Qué atiende |
|---|---|---|
| Consenso | Pipeline BFT, rotación de líderes por VRF, agregación BLS12-381 | Fases seriales y costo de mensajería/verificación casi O(n²) |
| Ejecución | Paralelismo optimista, agrupación dinámica, detección de conflictos en tres etapas | Techos del hilo único y radio de explosión de la reejecución |
| Estado | Particionado por cuenta/slot, cachés por capas, objetos grandes fuera de cadena con hashes en cadena | Capacidad de un solo árbol y presión de almacenamiento del nodo completo |
El consenso acuerda el orden con rapidez; la ejecución avanza las transiciones de estado en paralelo sobre lotes ordenados; el estado evita que «la ejecución se paralelice mientras el disco y la memoria siguen en un único punto». Quite cualquier capa y las cifras del cartel rara vez sobreviven a cargas reales. Coordenadas del producto: Posicionamiento de Bitroot.
Pipeline BFT: solapar alturas
El BFT clásico a menudo espera la secuencia proponer→votar→confirmar en una altura antes de empezar del todo la siguiente. Pipeline BFT canaliza las etapas: mientras la altura N está en preconfirmación, N+1 puede estar en prevotación y N+2 puede empezar a proponer. Los líderes rotan mediante VRF para reducir la manipulación predecible; la agregación BLS comprime muchas firmas de validadores hacia un costo de verificación casi constante, para que ampliar el conjunto no haga explotar linealmente el trabajo del consenso. Detalles y por qué importa el desacople: Pipeline BFT y desacople de la ejecución.
El desacople significa, en concreto: el consenso no necesita esperar la ejecución completa del bloque antes de avanzar el trabajo de ordenamiento en la siguiente altura. La ejecución puede ponerse al día de forma asíncrona. El precio de ingeniería es estricto: sea cual sea el paralelismo, el estado final debe coincidir con la ejecución serial bajo el orden del consenso, la restricción dura adicional que el OCC de cadena de bloques tiene sobre el OCC de bases de datos. Antecedentes: Introducción al OCC.
Paralelismo optimista: conservar la EVM y dejar la complejidad en el runtime
El paralelismo determinista (listas de cuentas explícitas) y los modelos de objetos suelen ganar en paralelismo teórico, a un alto costo de migración. El camino optimista supone que la mayoría de las transacciones no entran en conflicto, las ejecuta en paralelo y luego reejecuta de forma selectiva ante un conflicto. Los materiales de Bitroot insisten en la detección por capas —análisis de dependencias antes de la ejecución, monitoreo de versiones durante la ejecución, comprobaciones de raíz de estado después de la ejecución— para fallar antes y reducir la reversión. Análisis profundo: Paralelización optimista; contraste de la industria: Tres caminos hacia la ejecución paralela.
La planificación multi-motor, el paralelismo dentro del fragmento y la mensajería entre fragmentos son la expansión de ingeniería de ejecución y estado; véase Ejecución paralela multi-motor. Cuándo las cargas calientes se comen el dividendo del paralelismo: Hotspots de conflicto y cargas de trabajo.
Para los agentes de IA y los contratos de liquidación de trabajos, esta capa aporta expectativas planificables de confirmación y rendimiento; el entrenamiento en sí suele quedarse fuera de la ruta crítica del consenso; véase La pila de IA descentralizada.
Cómo leer las cifras de rendimiento (con salvedades)
Los materiales públicos y de testnet han citado confirmaciones del orden de cientos de milisegundos, miles a decenas de miles de TPS por fragmento y escalado con varios fragmentos; los lotes dependen del hardware, la mezcla de transacciones y la tasa de conflicto. No compare números brutos entre proyectos ni extrapole a garantías de mainnet o a retornos financieros. Conviene leer en conjunto las distribuciones de latencia, la tasa de conflicto y el costo de reproducción verificable; glosario: Glosario de métricas de rendimiento. Tensión de descentralización: Descentralización frente a rendimiento. Límite de compatibilidad: Qué significa la compatibilidad con EVM.
Que los carteles no omitan el almacenamiento ni la red
Una ejecución rápida igual choca con el almacenamiento y reparte votos por la red. Los objetos grandes pertenecen al fuera de cadena con hashes en cadena; las canalizaciones más profundas son más sensibles a la latencia de cola. Bajo carga real, la tasa de aciertos de la caché caliente y las colas entre fragmentos suelen hacerse visibles para el usuario antes que el núcleo puro de ejecución. Guía de público: Quién debería leer sobre la EVM paralela.
Los costos de compatibilidad pertenecen a la misma tabla: mantener la EVM a nivel de bytecode implica no poder exigir la predeclaración completa de lectura/escritura, así que los techos de paralelismo siguen el comportamiento de conflicto del runtime. Es lo opuesto a las cadenas de modelo de objetos que canjean paradigma de programación por paralelismo; véase Tres caminos hacia la ejecución paralela y Qué significa la compatibilidad con EVM. Los equipos que migran deberían validar la tasa de conflicto y la latencia p95 sobre trazas calientes antes que los picos de los carteles.
Vista del validador: el costo de reproducción es el presupuesto de descentralización
Los carteles de rendimiento suelen ignorar el costo de reproducción del validador. Si el paralelismo optimista crea muchas rutas especulativas y reejecuciones, la CPU y el ancho de banda del nodo completo suben, y los umbrales de validador siguen ese aumento. Esa es la tensión descentralización–rendimiento del lado de la ejecución. Los diseños deberían buscar aceleración paralela y a la vez permitir que los nodos honestos sigan reproduciendo de forma determinista y comprobando raíces de estado a un costo aceptable.
Evaluar sistemas de la clase de Bitroot significa, por tanto, preguntar no solo por la latencia de bloque del líder, sino también por las curvas de recursos para la sincronización y verificación de un nodo completo ordinario, y por la estrategia de instantáneas y poda tras el crecimiento del estado y el particionado. Véase Descentralización frente a rendimiento. Rutas de lectura: Quién debería leer sobre la EVM paralela.
Por qué el crecimiento del estado y la política de objetos grandes son arquitectura
Una vez que el paralelismo de ejecución ensancha la CPU, el estado histórico y los objetos grandes (calldata larga, metadatos, blobs de pruebas) se convierten en cuellos de botella de disco y sincronización. Las cargas fuera de cadena con hashes en cadena son comunes, pero necesitan supuestos de disponibilidad, ventanas de desafío y verificación de cliente ligero; de lo contrario, «lo paralelo es rápido» solo existe en bancos de prueba con estado vacío.
El particionado añade latencia entre fragmentos y semántica de atomicidad que cambian el modelo mental del desarrollador. Expansión: Ejecución paralela multi-motor. Celda del mapa: Mapear la escalabilidad de la cadena de bloques.
El panorama concluye en una línea: una EVM paralela es un sistema de tres capas —consenso, ejecución y estado—; optimice una sin medir las otras y las cargas reales lo expondrán. Abra los ensayos especializados para los parámetros; no los busque todos aquí.
Tres preguntas para llevar al leer este panorama
¿El orden de las transacciones sigue siendo predecible bajo congestión? Cuando los conflictos aumentan, ¿el rendimiento se degrada con elegancia en lugar de colapsar a cero? ¿El costo de reproducción del nodo completo aún permite un conjunto de validadores suficientemente disperso? Las narrativas de arquitectura se sostienen solo cuando los materiales de testnet responden a esto con condiciones; de lo contrario, siguen siendo listas de nombres de módulos.
Conclusión
El esqueleto de la EVM paralela de Bitroot es consenso canalizado para el ordenamiento, paralelismo optimista para las transiciones de estado, particionado para la escala del estado y compatibilidad con EVM para recortar la fricción de migración. El panorama termina aquí; para la profundidad de una capa, abra el ensayo correspondiente en lugar de esperar que un solo artículo agote a la vez las pruebas de consenso y el pseudocódigo del planificador.