---
id: 14
title: "Introduction au contrôle de concurrence optimiste (OCC) : des bases de données à l'exécution on-chain"
slug: optimistic-concurrency-control-intro
date: 2026/08/29
summary: Le contrôle de concurrence optimiste est né de la recherche sur les bases de données en 1981 et sous-tend aujourd'hui de nombreux EVM parallèles. Cette introduction explique les phases lecture–validation–écriture, oppose l'OCC au verrouillage pessimiste et au MVCC, et nomme les contraintes supplémentaires de déterminisme et de tolérance byzantine qu'ajoutent les chaînes de blocs.
keywords: contrôle de concurrence optimiste,OCC,ensembles lecture/écriture,sérialisabilité,EVM parallèle
heroImage: /images/community-bg.png
---

Les discussions sur l'EVM parallèle recyclent sans cesse les mêmes verbes : exécuter en parallèle, détecter les conflits, revenir en arrière et réessayer si nécessaire. Cela semble propre aux chaînes de blocs ; le squelette vient des bases de données. En 1981, H. T. Kung et John T. Robinson ont publié « On Optimistic Methods for Concurrency Control » dans ACM TODS, faisant de l'« optimisme » une méthode de concurrence analysable. Une fois cette logique claire, Block-STM ou un moteur d'EVM parallèle paraît bien moins mystérieux.

Cet article explique le pari de l'OCC et ses trois phases à travers le prisme des bases de données, le distingue du verrouillage pessimiste et du MVCC, puis énumère les contraintes que les chaînes de blocs ajoutent lorsqu'elles empruntent ce squelette. C'est un prérequis pour comprendre pourquoi le parallélisme optimiste convient aux voies compatibles EVM — et non un manuel de paramètres d'un produit particulier.

## Sur quoi parie l'optimisme

Le contrôle de concurrence traditionnel s'appuie sur des verrous : acquérir avant d'accéder, afin que personne ne modifie ce que vous lisez. Les verrous savent prouver la correction, mais les tables de verrous, la détection d'interblocages et les longues transactions qui conservent des verrous deviennent une surcharge visible sous forte concurrence. La proposition contre-intuitive de l'OCC : si les ensembles lecture/écriture de la plupart des transactions ne se recouvrent pas, laissez-les d'abord s'exécuter et reportez la vérification des conflits juste avant la validation, ce qui évite le coût des verrous pour des conflits qui ne se produiront peut-être jamais. L'article fondateur traite la reprise comme le contrôle principal — « optimiste » signifie parier que la contention est faible.

Cela ne nie pas les conflits ; cela déplace le moment où ils sont traités — de la prévention avant exécution à la validation juste avant le commit. Une fois le calendrier déplacé, le goulot de conception passe de « comment verrouiller finement » à « comment détecter à moindre coût et réduire les réexécutions ».

## Lecture, validation, écriture : le squelette en trois phases

L'OCC classique découpe une transaction en trois phases.

Phase de lecture : la transaction lit librement la base de données ; les écritures n'atterrissent que dans un espace de travail privé et ne polluent pas immédiatement l'état partagé. Pour les observateurs, les effets de bord non vérifiés sont invisibles ou ne sont visibles qu'au niveau de l'isolation.

Phase de validation : la transaction reçoit un horodatage ou un numéro de séquence ; le système vérifie si son ensemble de lecture est toujours valide — si des données ont été écrasées après la lecture par une autre transaction qui devrait la précéder dans l'ordre. Si l'ensemble de lecture est périmé, la validation échoue et la transaction avorte puis réessaie. La validation porte en réalité sur la sérialisabilité : l'entrelacement parallèle peut-il être équivalent à un certain ordre sériel ?

Phase d'écriture : une fois la validation réussie, fusionner l'ensemble d'écriture privé dans la base partagée. L'article distingue aussi la validation sérielle de la validation parallèle : la première lie validation et écriture en une étape atomique plus forte et plus simple ; la seconde autorise davantage de concurrence mais nécessite un mécanisme supplémentaire pour que les validations ne se contredisent pas.

Transposée à l'exécution parallèle d'une chaîne de blocs, la correspondance est presque bijective : les transactions s'exécutent spéculativement et collectent leurs ensembles lecture/écriture ; la validation se fait contre l'ordre fixe du bloc ; les valideurs appliquent l'état, et les échecs sont réexécutés en suivant les dépendances. Que le nom soit STM, Block-STM ou « EVM parallèle optimiste », le squelette reste l'OCC.

## Pourquoi le verrouillage pessimiste paraît lourd

Le verrouillage à deux phases (2PL) est le schéma pessimiste classique des bases de données relationnelles : une transaction n'acquiert que davantage de verrous jusqu'à sa fin. La correction est facile à démontrer ; le coût aussi — mémoire des verrous, interblocages, blocage en tête de file. Sous faible contention, la « taxe de prévention » du 2PL peut dépasser les réexécutions occasionnelles de l'OCC ; sous forte contention, les tempêtes de réexécution de l'OCC peuvent coûter plus cher que les verrous. L'OCC est donc depuis longtemps étiqueté comme « plus rentable quand la contention est faible ». On-chain, cela se traduit ainsi : lorsque les ensembles lecture/écriture d'un bloc se recouvrent à peine, le parallélisme optimiste gagne ; quand tout le monde frappe le même pool d'AMM, l'ingénierie doit borner la réexécution, sinon les chiffres sont mauvais.

C'est aussi pourquoi les divulgations de performance doivent nommer le type de charge et les conditions de test. Un flot de laboratoire constitué de virements sans lien et les routes de DEX en pointe sur le mainnet ont une structure de conflit totalement différente ; le même moteur OCC peut sembler séparé d'un ordre de grandeur.

## MVCC : apparenté, mais un autre bouton

Le contrôle de concurrence multi-version (MVCC) apparaît souvent à côté de l'OCC, mais répond à une autre question. Le MVCC permet aux lecteurs de voir un instantané cohérent, de sorte que les lecteurs ne bloquent pas les écrivains ; son cœur réside dans le stockage des versions et les règles de visibilité. Le cœur de l'OCC est ce qui se passe quand la validation échoue. Les deux se composent : utiliser les versions pour réduire les collisions lecture/écriture, puis la validation optimiste pour décider qui l'emporte dans les conflits écriture/écriture. Des systèmes comme Hekaton, Silo et TicToc montrent des variantes avec horodatages, validation décentralisée et attribution retardée des séquences — unis par l'aveu que le verrouillage purement pessimiste est trop coûteux sur du matériel multicœur, et par l'échange de versionnage plus validation différée contre du débit.

Pour les ingénieurs on-chain, cette clarification aide à lire articles et documents : « nous utilisons le MVCC » peut ne décrire que la représentation de l'état ; ce qui décide habituellement du comportement d'un EVM parallèle, c'est la règle de validation et le calendrier de réexécution — des questions de la famille OCC.

## Les règles supplémentaires qu'ajoutent les chaînes de blocs

L'OCC des bases de données suppose généralement une reprise locale et un client capable d'observer les avortements. Les chaînes de blocs ajoutent deux contraintes dures.

Premièrement, une relecture déterministe à l'échelle du réseau. Chaque nœud honnête doit atteindre le même état final pour le même bloc. L'exécution optimiste peut se paralléliser à l'intérieur d'un nœud, mais les validations doivent converger vers un état équivalent à l'ordre canonique ; « cette machine a soumis un ensemble d'écriture différent à cause de la chance de l'ordonnanceur » est proscrit. Les implémentations inscrivent donc un ordre prédéfini ou une séquence canonique dans le protocole, plutôt que de laisser l'ordonnancement des threads faire partie de la sémantique.

Deuxièmement, des environnements byzantins. Un exécuteur isolé ne peut pas être supposé honnête. Les nœuds peuvent mentir, omettre ou fabriquer des conflits pour ralentir les autres. Les moteurs parallèles s'inscrivent donc dans des flux de consensus et de vérification plus vastes : le consensus fixe l'ordre et le chemin de finalité ; l'exécution calcule efficacement et de manière déterministe la racine d'état ; les clients légers et les nœuds complets s'appuient sur un état final vérifiable, et non sur une conjecture optimiste intermédiaire.

Dans les travaux liés à Block-STM, l'équipe Aptos inscrit le moteur dans la tradition STM et OCC et insiste sur le fait de transformer l'« ordonnancement » d'une malédiction en une condition de performance : une fois l'ordre donné, le parallélisme ne fait qu'accélérer la convergence vers cet ordre. La même lecture vaut pour les EVM parallèles — les transactions EVM vivent déjà dans un monde où les blocs sont ordonnés ; l'OCC se dispute le multicœur sous cet ordre plutôt que d'annuler l'ordre.

## Ensembles lecture/écriture : simples en théorie, difficiles en ingénierie

Les ensembles de lecture et d'écriture des manuels se traduisent dans l'EVM par des soldes, des nonces, des emplacements de stockage et, occasionnellement, des effets de bord de journal ou de remboursement de gaz. Une clé trop grossière invente de faux conflits et gaspille du parallélisme ; une clé trop fine augmente le coût de suivi et de validation. Les sauts dynamiques, les appels externes et les proxies rendent l'analyse statique préalable incomplète — précisément pourquoi l'EVM peine avec la pré-déclaration déterministe et pourquoi la collecte des ensembles lecture/écriture à l'exécution est la norme.

Le fait qu'un conflit réexécute une seule transaction, sa fermeture de dépendances ou tout un lot décide de la latence de queue. Les bonnes implémentations d'OCC traitent l'échec de validation comme un chemin chaud attendu, et non comme une branche d'exception. Ces détails appartiennent aux moteurs concrets ; cette introduction ne vise qu'à forger le jugement : quand un EVM parallèle revendique un débit élevé, demandez les hypothèses de taux de conflit et la politique de réexécution avant de demander les conditions de testnet ou de benchmark.

## De l'intuition à l'article de positionnement suivant

Lire l'exécution d'une chaîne de blocs à travers l'OCC des bases de données ramène la discussion des slogans vers des mécanismes vérifiables : ce qui est supposé, ce que la validation contrôle, qui paie le coût des échecs. Bitroot et les autres projets d'EVM parallèle optimiste diffèrent rarement sur le « faut-il l'OCC » — ils diffèrent sur la manière dont les ensembles lecture/écriture sont capturés, dont les conflits sont stratifiés et dont le consensus se met en pipeline séparément de l'exécution. L'article suivant se concentre sur Bitroot : quelle case il occupe sur la carte de scalabilité et parmi les trois voies parallèles, où sont ses frontières, et quelles affirmations doivent rester étiquetées comme des objectifs d'ingénierie dans des conditions de test.

## Pour aller plus loin

- Précédent : [« Trois voies vers l'exécution parallèle : ordonnancement déterministe, OCC optimiste et modèles à objets »](/fr/blog/parallel-execution-approaches)
- Suivant : [« Positionner Bitroot : les frontières d'un Layer 1 à EVM parallèle optimiste »](/fr/blog/bitroot-positioning)
- Associés : [« La technologie EVM parallélisée de Bitroot expliquée : la parallélisation optimiste »](/fr/blog/bitrootevm-), [« Glossaire des métriques de performance : TPS, BPS, latence de confirmation, finalité et taux de conflit »](/fr/blog/performance-metrics-glossary)