--- id: 14 title: "Introducción al control de concurrencia optimista (OCC): de las bases de datos a la ejecución en cadena" slug: optimistic-concurrency-control-intro date: 2026/08/29 summary: El control de concurrencia optimista nació en la investigación de bases de datos de 1981 y hoy sostiene muchas EVM paralelas. Esta introducción explica las fases de lectura–validación–escritura, contrasta el OCC con el bloqueo pesimista y el MVCC, y nombra las restricciones adicionales de determinismo y de entorno bizantino que añaden las cadenas de bloques. keywords: control de concurrencia optimista,OCC,conjuntos de lectura/escritura,serializabilidad,EVM paralela heroImage: /images/community-bg.png --- Las discusiones sobre EVM paralela reciclan los mismos verbos: ejecutar en paralelo, comprobar conflictos, revertir y reintentar si hace falta. Eso suena nativo de la cadena; el esqueleto viene de las bases de datos. En 1981, H. T. Kung y John T. Robinson publicaron «On Optimistic Methods for Concurrency Control» en ACM TODS, convirtiendo lo «optimista» en un método de concurrencia analizable. Una vez clara esa lógica, Block-STM o un motor de EVM paralela se ven mucho menos misteriosos. Este artículo explica la apuesta del OCC y sus tres fases con la lente de las bases de datos, lo separa del bloqueo pesimista y del MVCC, y luego enumera las restricciones que añaden las cadenas de bloques cuando toman prestado el esqueleto. Es material previo para entender por qué el paralelismo optimista encaja en las rutas compatibles con EVM, no un manual de parámetros de un producto concreto. ## A qué apuesta el optimismo El control de concurrencia tradicional se apoya en bloqueos: adquirir antes de acceder para que nadie modifique lo que estás leyendo. Los bloqueos pueden demostrar corrección, pero las tablas de bloqueos, la detección de interbloqueos y las transacciones largas que retienen bloqueos se vuelven sobrecarga visible bajo alta concurrencia. La propuesta contraintuitiva del OCC: si los conjuntos de lectura/escritura de la mayoría de las transacciones no se solapan, déjelas correr primero y posponga las comprobaciones de conflicto hasta justo antes de la confirmación, evitando el costo de los bloqueos para conflictos que quizá nunca ocurran. El artículo trata la reversión como el control principal: «optimista» significa esperar que la contención sea escasa. Eso no niega los conflictos; traslada cuándo se manejan, de prevenir antes de ejecutar a validar cerca de la confirmación. Una vez que el momento cambia, el cuello de botella del diseño pasa de «cómo bloquear con granularidad fina» a «cómo detectar barato y cómo reducir el rehacer». ## Lectura, validación, escritura: el esqueleto de tres fases El OCC clásico divide la transacción en tres fases. Fase de lectura: la transacción lee la base de datos con libertad; las escrituras quedan solo en un espacio de trabajo privado y no contaminan de inmediato el estado compartido. Para los observadores, los efectos secundarios no verificados son invisibles o solo visibles según el aislamiento. Fase de validación: la transacción recibe una marca de tiempo o un número de secuencia; el sistema comprueba si su conjunto de lectura sigue siendo válido, es decir, si los datos fueron sobrescritos después de la lectura por otra transacción que debería precederla en el orden. Si el conjunto de lectura quedó obsoleto, la validación falla y la transacción aborta y reintenta. La validación trata en realidad de serializabilidad: ¿puede el entrelazado paralelo equivaler a algún orden serial? Fase de escritura: una vez que pasa la validación, el conjunto de escritura privado se fusiona con la base de datos compartida. El artículo también distingue la validación serial de la paralela: la primera une validar y escribir en un paso atómico más fuerte y es más simple; la segunda permite más concurrencia pero necesita maquinaria extra para que las confirmaciones no se contradigan. Llevado a la ejecución paralela en cadena, la correspondencia es casi uno a uno: las transacciones se ejecutan de forma especulativa y recolectan conjuntos de lectura/escritura; se validan contra el orden fijo del bloque; los confirmadores aplican el estado y los fallos se reejecutan siguiendo las dependencias. Ya se llame STM, Block-STM o «EVM paralela optimista», el esqueleto sigue siendo OCC. ## Por qué el bloqueo pesimista se siente pesado El bloqueo en dos fases (2PL) es el esquema pesimista clásico de las bases de datos relacionales: una transacción solo adquiere más bloqueos hasta que termina. La corrección es fácil de argumentar, y también el costo: memoria de bloqueos, interbloqueos, bloqueo en cabeza de línea. Bajo contención baja, el «impuesto de prevención» del 2PL puede superar el rehacer ocasional del OCC; bajo contención alta, las tormentas de rehacer del OCC pueden costar más que los bloqueos. Por eso el OCC lleva mucho tiempo etiquetado como «rinde más cuando la contención es baja». En cadena, eso se traduce en: cuando los conjuntos de lectura/escritura dentro de un bloque apenas se solapan, gana el paralelismo optimista; cuando todos golpean el mismo pool de AMM, la ingeniería debe acotar la reejecución o los números se ven mal. Esa es también la razón de que las divulgaciones de rendimiento deban indicar el tipo de carga y las condiciones de prueba. Los aluviones de laboratorio de transferencias sin relación y las rutas pico de un DEX en la mainnet tienen estructuras de conflicto totalmente distintas; el mismo motor OCC puede sentirse a un orden de magnitud de distancia. ## MVCC: emparentado, pero es otra perilla El control de concurrencia multiversión (MVCC) suele aparecer junto al OCC, pero responde a otra pregunta. El MVCC deja que los lectores vean una instantánea consistente y así no bloqueen a los escritores; el núcleo es el almacenamiento de versiones y las reglas de visibilidad. El núcleo del OCC es qué ocurre cuando falla la validación. Se componen: use versiones para reducir el pisoteo entre lecturas y escrituras, y luego validación optimista para decidir quién gana los conflictos de escritura/escritura. Sistemas como Hekaton, Silo y TicToc muestran variantes con marcas de tiempo, validación descentralizada y asignación de secuencias diferida, unidas por admitir que el bloqueo puramente pesimista es demasiado caro en hardware multinúcleo, y por canjear versionado más validación diferida por rendimiento. Para los ingenieros de cadena, la aclaración ayuda al leer artículos y documentos: «usamos MVCC» puede describir solo la representación del estado; lo que suele decidir el comportamiento de una EVM paralela son la regla de validación y el calendario de reejecución, cuestiones de la familia OCC. ## Reglas extra que añaden las cadenas de bloques El OCC de bases de datos suele asumir reintento local y un cliente que puede observar los abortos. Las cadenas de bloques añaden dos restricciones duras. Primero, la reproducción determinista en toda la red. Cada nodo honesto debe alcanzar el mismo estado final para el mismo bloque. La ejecución optimista puede paralelizar dentro de un nodo, pero las confirmaciones deben converger a un estado equivalente al orden canónico; se prohíbe que «esta máquina envió un conjunto de escritura distinto por suerte del planificador». Las implementaciones, por tanto, incorporan un orden preestablecido o una secuencia canónica al protocolo, en lugar de dejar que la planificación de hilos forme parte de la semántica. Segundo, entornos bizantinos. No se puede asumir que un único ejecutor sea honesto. Los nodos pueden mentir, omitir o fabricar conflictos para frenar a otros. Los motores paralelos, por tanto, se insertan en flujos mayores de consenso y verificación: el consenso fija el orden y la ruta de finalidad; la ejecución calcula de forma eficiente y determinista la raíz de estado; los clientes ligeros y los nodos completos se apoyan en el estado final verificable, no en una conjetura optimista intermedia. En el trabajo relacionado con Block-STM, el equipo de Aptos ubica el motor en la tradición del STM y el OCC y subraya convertir el «ordenamiento» de una maldición en una condición de rendimiento: una vez dado el orden, el paralelismo solo acelera la convergencia a ese orden. La misma lectura encaja en las EVM paralelas: las transacciones de la EVM ya viven en un mundo donde los bloques están ordenados; el OCC compite por los múltiples núcleos bajo ese orden en lugar de cancelar el orden. ## Conjuntos de lectura/escritura: simples en abstracto, difíciles en ingeniería Los conjuntos de lectura y escritura de los libros de texto se traducen en la EVM a saldos, nonces, slots de almacenamiento y algunos efectos secundarios de logs o reembolsos. Una clave demasiado gruesa inventa conflictos falsos y desperdicia paralelismo; demasiado fina eleva el costo de seguimiento y validación. Los saltos dinámicos, las llamadas externas y los proxies hacen que el preanálisis estático quede incompleto, justo por eso la EVM tiene dificultades con la predeclaración determinista y por eso la recolección de conjuntos de lectura/escritura en el runtime es lo habitual. Si un conflicto reejecuta una transacción, su cierre de dependencias o un lote entero decide la latencia de cola. Las implementaciones fuertes de OCC tratan el fallo de validación como una ruta crítica esperada, no como una rama de excepción. Esos detalles pertenecen a motores concretos; esta introducción solo construye criterio: cuando una EVM paralela afirma alto rendimiento, pregunte por los supuestos de tasa de conflicto y la política de reejecución antes de pedir las condiciones de testnet o de benchmark. ## De la intuición a la siguiente pieza de posicionamiento Leer la ejecución en cadena a través del OCC de bases de datos lleva la discusión de los eslóganes de vuelta a mecanismos comprobables: qué se asume, qué comprueba la validación, quién paga el costo del fallo. Bitroot y otros proyectos de EVM paralela optimista rara vez difieren en «si usan OCC»; difieren en cómo capturan los conjuntos de lectura/escritura, cómo estratifican los conflictos y si el consenso se canaliza por separado de la ejecución. El artículo siguiente se centra en Bitroot: qué celda ocupa en el mapa de escalabilidad y entre los tres caminos paralelos, dónde están sus límites y qué afirmaciones deberían seguir etiquetadas como objetivos de ingeniería bajo condiciones de prueba. ## Lecturas relacionadas - Anterior: ["Tres caminos hacia la ejecución paralela: planificación determinista, OCC optimista y modelos de objetos"](/es/blog/parallel-execution-approaches) - Siguiente: ["Posicionamiento de Bitroot: los límites de un Layer 1 con EVM paralela optimista"](/es/blog/bitroot-positioning) - Relacionado: ["La tecnología de EVM paralelizada de Bitroot explicada: paralelización optimista"](/es/blog/bitrootevm-), ["Glosario de métricas de rendimiento: TPS, BPS, latencia de confirmación, finalidad y tasa de conflicto"](/es/blog/performance-metrics-glossary)