La parallélisation optimiste en une ligne : supposez que la plupart des transactions n'entrent pas en collision, exécutez-les en parallèle ; en cas de conflits lecture/écriture, refaites dans l'ordre fixé jusqu'à ce que les résultats correspondent à l'exécution sérielle. Ce n'est pas de la « magie plus rapide » — cela déplace la gestion des conflits de la prévention vers la détection et la reprise. Lorsque l'EVM ne peut pas imposer de listes d'accès de comptes, c'est presque la voie principale qui préserve la compatibilité du bytecode. Théorie : Introduction à l'OCC ; voies : Trois voies vers l'exécution parallèle. Place dans l'architecture : Vue d'ensemble de l'architecture EVM parallèle de Bitroot et Positionnement de Bitroot.
Pourquoi l'EVM résiste à la pré-déclaration déterministe
Solana Sealevel exige des listes de comptes déclarées afin que les ordonnanceurs puissent construire un graphe avant l'exécution. Les emplacements de stockage qu'une transaction EVM touche n'apparaissent souvent qu'après les branchements conditionnels. Imposer des listes d'accès casse de nombreux contrats existants et hypothèses de chaînes d'outils. Des projets comme Bitroot choisissent donc d'abord la compatibilité et laissent les conflits à l'exécution. Frontière de compatibilité : Ce que signifie la compatibilité EVM.
Le coût : des taux de conflit élevés rongent le dividende du parallélisme via la réexécution. Ce n'est pas « une implémentation boguée » — c'est la courbe inhérente à la méthode optimiste, en particulier sur les contrats chauds — voir Points chauds de conflit et charges de travail.
Ce que fait la détection de conflits en trois étapes
Les documents Bitroot décrivent trois étapes par responsabilité (les algorithmes concrets suivent les implémentations des nœuds) :
-
Avant l'exécution — analyse statique/heuristique des dépendances
Utiliser les motifs historiques, l'analyse statique ou des estimations grossières de lecture/écriture pour garder les conflits évidents hors de la même fenêtre parallèle. -
Pendant l'exécution — surveillance des versions ou des ensembles lecture/écriture
Les transactions s'exécutent sur des vues privées ; si une version lue a déjà été écrite par une transaction ordonnée plus tôt, interrompre tôt au lieu de terminer un travail inutile. -
Après l'exécution — vérifications de la racine d'état / de sérialisabilité
Vérifier la cohérence des candidats à la validation afin que les résultats parallèles fusionnés correspondent à la sémantique sérielle canonique, en rattrapant les oublis et les bogues d'implémentation.
Par rapport à un OCC naïf qui termine tout le lot avant une seule passe de validation, la détection en couches vise à échouer plus tôt avec un ensemble de réexécution plus petit. Cela partage une famille de problèmes avec l'ordonnancement collaboratif de Block-STM, sans ordonnanceurs ni granularité d'interruption identiques — ne remplacez pas les courbes de taux de conflit par des multiples marketing.
Retour en arrière et réexécution : sélectifs, pas une reprise de tout le bloc
Les implémentations efficaces ne relancent généralement que les transactions concernées et leur fermeture de dépendances — pas chaque transaction du bloc. L'ordre du consensus reste contraignant : on ne peut pas réordonner silencieusement pour le débit. D'abord ordonner, converger ensuite : Pipeline BFT et découplage de l'exécution. Comment les multi-moteurs hébergent les fenêtres parallèles : Exécution parallèle multi-moteur.
Pour les agents et le règlement à haute fréquence, cela signifie : la confirmation peut être prévisible en cas de faible conflit ; sur des pools chauds, attendez-vous à une hausse des réexécutions — ne supposez pas que « parallèle = toujours rapide ». Contexte de pile : La pile d'IA décentralisée.
Déterminisme : la couche supplémentaire exigée par l'OCC de chaîne de blocs
L'OCC d'une base de données mono-nœud n'a besoin de sérialisabilité que sur cette instance. On-chain, chaque nœud honnête doit calculer indépendamment le même état. Il faut donc interdire toute dépendance à l'ordre d'ordonnancement des threads, aux horloges locales, à la virgule flottante instable et à d'autres non-déterminismes similaires. Lorsque le parallélisme change, le résultat canonique doit rester unique. C'est une propriété de sûreté, et non un bonus de performance.
Comparaison des approches des pairs (mesurée)
| Voie | Intuition centrale | EVM existant |
|---|---|---|
| Déclaration déterministe | Dépendances connues avant l'exécution | Coût de migration élevé |
| Modèle à objets | Isoler via la propriété des objets | Nouveau langage/paradigme |
| OCC optimiste | Détection à l'exécution + réexécution | Le plus proche de la compatibilité bytecode |
Les affirmations publiques de « débit multiplié par rapport à l'EVM classique » doivent être lues comme des observations d'ingénierie sous des charges spécifiques et des conditions de testnet ; les multiples se réduisent en cas de conflit élevé. Guide de lecture : Glossaire des métriques de performance. Comment les seuils de validateurs limitent le parallélisme utilisable : Compromis décentralisation–performance. Ceci n'est pas un conseil en investissement.
Les courbes de conflit valent mieux que les multiples de pointe
Un « Nx par rapport à l'EVM sériel » en laboratoire correspond généralement à une charge synthétique à faible conflit ; le même moteur sur des points chauds de pools partagés réduit vite le multiple. Préférez les courbes conflit–débit, la part de réexécution et la latence p95 à un unique facteur de multiplication. Anatomie des points chauds : Points chauds de charge de l'EVM parallèle.
Les détails des clients diffèrent, mais les grilles d'évaluation peuvent être communes : granularité des ensembles lecture/écriture (compte ou emplacement), réexécution immédiate ou mise en file des interruptions, parallélisme de la validation, et mode de finalisation de la racine d'état après fusions parallèles. Plus la grille est concrète, plus il est difficile d'esquiver les « trois étapes ». Filiation base de données : Introduction à l'OCC ; architecture : Vue d'ensemble de l'architecture EVM parallèle de Bitroot.
Courbes de taux de conflit et leviers d'ingénierie
Les leviers clés ne sont pas « plus de moteurs, c'est toujours mieux », mais la largeur de la fenêtre parallèle, la politique d'interruption, la priorité de réexécution et le degré de prudence de l'analyse heuristique. Des fenêtres trop larges allongent les cascades de conflits ; trop étroites, elles tendent vers l'exécution sérielle. Des heuristiques trop prudentes plafonnent le débit ; trop agressives, elles invitent des tempêtes de réexécution.
Les tests publics devraient rapporter une base sans conflit, une charge synthétique à conflit moyen et une charge de résistance proche d'un point chaud d'AMM. Ne publier que le premier chiffre montre la borne supérieure lorsque les hypothèses optimistes tiennent. Glossaire : Glossaire des métriques de performance. Taxonomie des charges : Points chauds de conflit et charges de travail.
OCC de chaîne de blocs vs OCC de base de données — encore
Les bases de données peuvent valider sur un primaire puis répliquer ; les chaînes exigent que chaque réplique honnête converge indépendamment vers la même racine. « Presque sérialisable » ne suffit pas — le déterminisme est obligatoire. Les sorties de modèles en virgule flottante, l'entropie locale et les réductions parallèles non ordonnées ne doivent pas entrer dans les transitions d'état canoniques ; elles peuvent rester hors ligne et s'ancrer via des preuves ou des signatures agrégées.
C'est pourquoi l'inférence d'IA ne doit pas alimenter directement le consensus : des sorties probabilistes entrent en conflit avec la relecture déterministe. Le schéma est : calcul hors ligne, règlement on-chain, preuves facultatives — La pile d'IA décentralisée, Cadre d'informatique de confiance.
La valeur pédagogique de la parallélisation optimiste est de traduire « rapide » en taux de conflit et part de réexécution mesurables. Gardez cette traduction et la prochaine affiche de TPS plus élevé sera plus difficile à croire sans recul. Les détails d'implémentation suivent toujours le code client et les audits.
Tests de correction (conceptuels)
Au-delà des bancs de débit : un même lot produit une seule racine d'état à tous les niveaux de parallélisme ; des conflits lecture/écriture injectés convergent toujours vers une équivalence sérielle ; la relecture après reprise sur incident n'introduit pas de fork ; des flux aléatoires testés par fuzzing correspondent entre modes parallèle et sériel. Réussir ces tests en dit plus sur une parallélisation optimiste bien conçue qu'une nouvelle affirmation de TPS de pointe.
Détection, réexécution et déterminisme forment le triangle du parallélisme optimiste : sans détection, les retours en arrière arrivent tard ; sans réexécution sélective, le débit s'effondre ; sans déterminisme, le modèle de sûreté échoue. C'est seulement avec les trois que les chiffres de TPS s'expliquent d'eux-mêmes.
Publiez les accélérations avec le taux de conflit et la part de réexécution ; évitez les pics isolés. Ceci n'est pas un conseil en investissement.
Les algorithmes concrets suivent les implémentations des nœuds et les audits ; cet article ne fait que construire l'intuition des mécanismes.
À retenir
La parallélisation optimiste permet à Bitroot d'extraire des gains multicœur sans forcer les développeurs à réécrire leurs schémas d'accès ; son plafond est fixé par le taux de conflit et l'efficacité de réexécution — non par des adjectifs de livre blanc. Comprendre les couches de détection et les contraintes de déterminisme est plus utile que de mémoriser un chiffre de TPS.