---
id: 13
title: "Tres caminos hacia la ejecución paralela: planificación determinista, OCC optimista y modelos de objetos"
slug: parallel-execution-approaches
date: 2026/08/27
summary: Tres caminos maduros rompen el techo de la ejecución de un solo hilo: la predeclaración determinista al estilo Sealevel, el control de concurrencia optimista al estilo Block-STM y los modelos de objetos al estilo Sui. Este artículo compara sus supuestos, sus costos para el desarrollador y su encaje con la compatibilidad con EVM.
keywords: ejecución paralela,Sealevel,Block-STM,control de concurrencia optimista,modelo de objetos
heroImage: /images/community-bg.png
---

Una EVM de un solo hilo compra determinismo a un precio relativamente bajo: orden fijo y repetición simple. Cuando el objetivo pasa a ser "aumentar el ancho de ejecución sin romper la corrección verificable", los diseñadores se topan con la misma bifurcación: quién decide si dos transacciones pueden ejecutarse juntas, ¿el desarrollador de antemano o el runtime después?

Esa elección da forma al modelo de programación, al costo de migración y al rendimiento real bajo contención alta. La industria ha recorrido tres caminos relativamente claros: el paralelismo determinista que ejemplifica Sealevel, en Solana; el control de concurrencia optimista (OCC) que ejemplifican Block-STM, en Aptos, y varias EVM paralelas; y el modelo de objetos que ejemplifica Sui. Los tres "paralelizan", con supuestos y costos muy distintos.

## Paralelismo determinista: las dependencias escritas en la transacción

El camino determinista exige que cada transacción lleve una lista completa de las cuentas (o recursos) que va a leer y escribir, marcadas como de solo lectura o de escritura. Antes de ejecutar, el runtime puede construir un grafo: si no hay conflicto de escritura, es seguro paralelizar; las lecturas compartidas pueden co-programarse; las escrituras compartidas se serializan. El planificador no necesita adivinar dependencias en pleno vuelo; la estructura de conflictos se conoce aproximadamente al momento de encolar. Sealevel, en Solana, es la muestra de ingeniería más citada, muy acoplada a su modelo de cuentas y a su almacenamiento en el runtime.

La ventaja es la previsibilidad: una vez aceptada, la ruta de ejecución desperdicia menos trabajo en "descubrir un conflicto a mitad de camino y abortar todo el intento". El costo recae en los desarrolladores y las herramientas. Las transferencias simples son baratas de declarar; los programas con ramas complejas cuyas rutas de acceso dependen de condiciones del runtime deben sobredeclarar (reduciendo el paralelismo) o subdeclarar (haciendo fallar la transacción). El acceso clásico a slots de almacenamiento de la EVM suele decidirse por condiciones dentro del contrato; el bytecode no lleva una lista de cuentas al estilo Sealevel. Forzar la predeclaración rompe de inmediato la compatibilidad a nivel de bytecode: hay que reescribir los contratos y los supuestos de auditoría.

La predeclaración tampoco elimina los hotspots de la aplicación. Los pools de DEX, las liquidaciones y los mints calientes siguen concentrando las escrituras en unas pocas cuentas; las cadenas de conflicto se alargan; el paralelismo queda condicionado por el diseño del estado, no por el planificador. El determinismo resuelve "¿conocemos las dependencias al momento de planificar?", no "¿se ha distribuido el estado?". Cómo las cargas de trabajo crean hotspots corresponde a otro análisis; aquí basta notar que ningún motor rescata una estructura de contrato en la que todos contienden por el mismo slot.

## Control de concurrencia optimista: asumir paralelismo y converger sobre los errores

El OCC invierte la apuesta: la mayoría de las transacciones no entran en conflicto, así que se ejecutan en paralelo primero y luego se valida si los conjuntos de lectura siguen siendo válidos; ante un conflicto, se aborta y se reejecuta en el orden canónico hasta que el resultado sea igual a algún orden serial. La memoria transaccional por software (STM) y el OCC de las bases de datos aportan el esqueleto teórico; Block-STM, en Aptos, es una instancia ampliamente citada en el ámbito de las cadenas de bloques: ejecución optimista bajo un orden preestablecido, con una planificación colaborativa que descubre dependencias durante la ejecución y rehace el trabajo, con el objetivo de revertir solo las transacciones realmente afectadas.

Las cifras altas de TPS en materiales públicos suelen provenir de benchmarks, hardware y mezclas de transacciones específicos (por ejemplo, transacciones Move no triviales en entornos de laboratorio o de prueba). No son intercambiables con la experiencia de la mainnet bajo carga mixta. Lo que importa es la forma del mecanismo: la corrección depende de "ser eventualmente equivalente a un orden dado"; el rendimiento depende de "que las tasas de conflicto sean lo bastante bajas o la reejecución lo bastante barata".

Varias cadenas compatibles con EVM eligen OCC por una razón coherente: al recibir una transacción no se puede saber de forma estática todos los accesos a almacenamiento; solo la ejecución los revela. El runtime registra los conjuntos reales de lectura/escritura; los subconjuntos en conflicto convergen en serie; el resto conserva las ganancias del paralelismo. Monad, Sei y otros difieren en instantáneas, orden de confirmación y en si el consenso se desacopla de la ejecución, pero comparten "sin predeclaración por parte del desarrollador" como premisa de compatibilidad.

El riesgo central del OCC es igual de público: cuando las tasas de conflicto se disparan, la reejecución se come el excedente del paralelismo y, en casos extremos, el rendimiento puede acercarse o caer por debajo de una estrategia serial ingenua con bloqueos. La reversión selectiva, la detección en vuelo, el agrupamiento en lotes y la granularidad de los conjuntos de lectura/escritura deciden el costo de cola cuando la apuesta optimista falla. El siguiente artículo explica las fases de lectura–validación–escritura del OCC desde la perspectiva de las bases de datos.

## Modelos de objetos: cambiar la forma del libro mayor para cambiar los límites del paralelismo

El tercer camino no parchea el modelo de cuentas; cambia la estructura del libro mayor. Sui modela los activos como objetos con identificadores únicos, divididos en objetos propios y compartidos. Los objetos propios tienen un único escritor, de modo que las transacciones relacionadas pueden tomar una ruta de menor latencia y con menos necesidad de orden global. Los objetos compartidos admiten muchos accesos y deben ordenarse mediante consenso. El paralelismo se convierte en un problema de propiedad: los flujos naturalmente de un solo dueño escalan; el estado verdaderamente compartido entre varias partes paga el precio del orden global.

El modelo es amable con los NFT y las transferencias de activos entre pares; los pools de AMM, las subastas globales y otras aplicaciones con muchos objetos compartidos siguen chocando con contención caliente, ahora con granularidad de objeto en lugar de granularidad de cuenta-slot. El costo es la migración de paradigma y de lenguaje: Move y la propiedad de objetos difieren del modelo de cuentas de Solidity. Los contratos de Ethereum existentes y los flujos de trabajo con Foundry/Hardhat no se "trasladan y ya"; los ecosistemas pagan costos de aprendizaje y auditoría a cambio del paralelismo.

Los modelos de objetos demuestran que el paralelismo de ejecución no tiene por qué ser solo planificación "declarativa" u "optimista": la topología del estado es otra palanca. También les recuerdan a las rutas compatibles con EVM que conservar cuentas y estado global implica renunciar a parte del paralelismo estructural que compra el modelo de objetos, de modo que la planificación en el runtime debe soportar más carga.

## Cómo se comparan los tres caminos

| Dimensión | Determinista (estilo Sealevel) | OCC optimista (estilo Block-STM) | Modelo de objetos (estilo Sui) |
|-----------|-------------------------------|----------------------------------|-------------------------|
| Cuándo se conocen las dependencias | Se declaran antes del envío | Se descubren durante o después de la ejecución | Se derivan de la propiedad de los objetos |
| Carga para el desarrollador | Alta (listas de acceso) | Baja (conserva el estilo de contrato habitual) | Alta (modelo/lenguaje nuevos) |
| Encaje con la EVM clásica | Difícil (choque semántico) | Relativamente viable | Requiere migración |
| Modo principal de fallo | Sobredeclaración/subdeclaración; los hotspots igual se serializan | Tormentas de reejecución con conflictos altos | Hotspots de objetos compartidos; migración del ecosistema |

El patrón es claro: si la restricción dura del producto es la compatibilidad a nivel de bytecode con los contratos y herramientas de Ethereum existentes, tanto la predeclaración determinista como los modelos de objetos obligan a reescribir o a cambiar de pila, por lo que las opciones reales suelen converger en el OCC. No es una afirmación de que el OCC sea teóricamente el mejor bajo toda carga —los caminos determinista y de objetos han mostrado un rendimiento sólido en sus ecosistemas—, sino el reconocimiento de que la compatibilidad comprime el espacio de diseño.

Para un L1 posicionado como EVM paralela optimista, elegir OCC es convergencia bajo restricciones, no un eslogan. Las verdaderas preguntas de ingeniería pasan a ser cómo definir los conjuntos de lectura/escritura, con cuánta anticipación detectar los conflictos y cómo acotar la reejecución bajo carga alta. Todo eso se apoya en la intuición de bases de datos del OCC y en una evaluación honesta de los hotspots de carga.

## Lecturas relacionadas

- Anterior: ["Mapear la escalabilidad de la cadena de bloques: qué resuelve cada enfoque —paralelismo en L1, L2, sharding y disponibilidad de datos"](/es/blog/blockchain-scaling-map)
- Siguiente: ["Introducción al control de concurrencia optimista (OCC): de las bases de datos a la ejecución en cadena"](/es/blog/optimistic-concurrency-control-intro)
- Relacionado: ["La tecnología de EVM paralelizada de Bitroot explicada: paralelización optimista"](/es/blog/bitrootevm-), ["Hotspots de conflicto y cargas de trabajo: cuándo ayuda de verdad una EVM paralela"](/es/blog/parallel-evm-workload-hotspots)