Un EVM parallèle est-il un nouveau langage de contrat intelligent ?

Non. L'objectif est généralement d'exécuter le bytecode EVM existant et de prendre en charge l'outillage Solidity, tout en modifiant la manière dont le logiciel des nœuds ordonnance et valide les transactions en interne sur les cœurs du processeur.

Deux transactions touchant le même contrat peuvent-elles s'exécuter en parallèle ?

C'est possible si elles accèdent à des stockages différents et que le moteur peut prouver ou valider leur indépendance. Le simple fait de partager une adresse de contrat ne crée pas toujours un conflit, mais le partage de clés d'état en crée souvent un.

Que se passe-t-il lorsque des transactions parallèles entrent en conflit ?

Le moteur détecte la dépendance invalide, écarte ou retarde le résultat provisoire concerné, puis l'exécute à nouveau sur l'état antérieur correct. Certains systèmes basculent vers un traitement séquentiel en cas de forte contention.

La compatibilité avec un EVM parallèle garantit-elle une sécurité de niveau Ethereum ?

Non. La compatibilité concerne le comportement d'exécution. Le consensus, la répartition des validateurs, le stockage de l'état, les ponts, la gouvernance, les permissions de mise à niveau, la finalité et la disponibilité des données déterminent des aspects distincts du modèle de sécurité d'un réseau.

Qu'est-ce qu'un EVM parallèle et comment fonctionne l'exécution parallèle ?

Un EVM parallèle est une implémentation d' Ethereum Virtual Machine ou un moteur d'exécution compatible EVM qui traite simultanément des transactions indépendantes sur plusieurs cœurs de CPU. Les transactions conservent un ordre déterministe et doivent produire le même état final qu'une exécution EVM séquentielle valide. La parallélisation modifie la façon dont les nœuds calculent leurs résultats en interne, et non la signification des contrats Solidity ni l'état ordonné du registre que les utilisateurs observent.

Cette conception cible un goulot d'étranglement d'exécution propre au traitement monothread classique. Lorsque des transactions touchent des comptes ou des emplacements de stockage sans lien entre eux, un nœud peut les traiter en même temps. En cas de conflit, le moteur doit détecter la dépendance, écarter ou retarder un résultat spéculatif invalide, puis exécuter la transaction concernée sur l'état antérieur correct. Les performances dépendent donc largement de la contention de la charge de travail et de la conception du stockage.

Qu'est-ce qu'un EVM parallèle ?

Un EVM parallèle est un environnement d'exécution compatible Ethereum capable de traiter plusieurs transactions indépendantes en même temps, plutôt que d'exécuter chaque transaction strictement l'une après l'autre. Il vise à préserver les contrats intelligents, les adresses, les formats de transaction et les outils de développement EVM familiers, tout en améliorant le débit de traitement des transactions.

Les implémentations d'EVM parallèle peuvent recourir à différentes méthodes pour déterminer quelles transactions peuvent s'exécuter ensemble en toute sécurité. Certaines détectent les conflits pendant l'exécution, d'autres analysent les parties de l'état de la blockchain auxquelles chaque transaction accédera avant de les ordonnancer. L'EVM parallèle désigne donc une approche d'exécution plutôt qu'une norme universelle, et les réseaux peuvent encore différer par le consensus, les frais, la finalité, les exigences matérielles et la compatibilité avec Ethereum.

Comment fonctionne un EVM parallèle ?

Un EVM parallèle fonctionne en répartissant les transactions d'un bloc ordonné entre plusieurs workers et en suivant l'état que chaque transaction lit et écrit. Avec l'exécution optimiste, les workers supposent d'abord que les transactions peuvent s'exécuter ensemble. Leurs résultats restent provisoires jusqu'à ce que le moteur vérifie qu'une transaction antérieure n'a pas modifié une entrée utilisée par une transaction ultérieure. Les résultats sans conflit peuvent être validés selon l'ordre d'origine du bloc.

Si une transaction ultérieure a lu des données périmées ou si ses écritures entrent en conflit, son résultat provisoire est rejeté et la transaction est réexécutée dès que l'état antérieur requis devient disponible. Certains moteurs peuvent réutiliser les signatures, le bytecode décodé, l'état mis en cache ou d'autres travaux lors de la réexécution. Un repli séquentiel préserve la progression en cas de forte contention. Chaque validateur doit appliquer des règles déterministes de conflit et de validation afin que l'ordonnancement parallèle ne puisse pas créer des racines d'état différentes.

Quels sont les principaux avantages et cas d'usage d'un EVM parallèle ?

Les conceptions d'EVM parallèle sont les plus efficaces lorsqu'un bloc contient de nombreuses transactions portant sur des états distincts. Elles visent à accroître la capacité d'exécution des nœuds sans imposer aux développeurs Solidity et aux utilisateurs un environnement inconnu.

1. Plusieurs cœurs peuvent traiter un travail indépendant. Les transferts et les appels de contrats touchant des comptes ou des emplacements de stockage différents peuvent s'exécuter simultanément, en exploitant plus pleinement le matériel moderne des validateurs qu'un seul fil d'exécution.

2. Les applications EVM peuvent conserver un outillage familier. Les réseaux compatibles peuvent prendre en charge les contrats Solidity, les portefeuilles de type Ethereum, les interfaces JSON-RPC et les frameworks de développement, tout en modifiant l'exécution sous la couche applicative.

3. Les applications à fort volume gagnent en marge d'exécution. Les paiements, les jeux, les plateformes d'échange et les applications sociales à état distribué peuvent traiter des blocs plus volumineux lorsque leurs transactions génèrent relativement peu de conflits d'état partagé.

4. L'optimisation peut rester transparente pour les contrats. Les moteurs optimistes tels que Monad valident les résultats comme si les transactions s'exécutaient séquentiellement, si bien que les développeurs n'ont pas besoin de découper manuellement des contrats ordinaires simplement pour activer la concurrence.

Quels sont des exemples de moteurs d'exécution parallèle ?

Les projets recourent à l'exécution parallèle avec différentes machines virtuelles et différents modèles d'état. Les systèmes non-EVM restent des références utiles, car plusieurs techniques de concurrence optimiste ont d'abord été développées ou déployées en dehors de l'EVM.

Monad : l'EVM parallèle optimiste. Monad exécute simultanément des transactions compatibles Ethereum, suit leurs entrées et réexécute une transaction lorsqu'un résultat validé antérieurement a modifié les données qu'elle utilisait.
Sei : le moteur de parallélisation. Sei utilise le contrôle de concurrence optimiste, des ensembles d'accès estimés, une exécution par workers, la détection de conflits, un retraitement déterministe et un repli séquentiel autour de son environnement EVM.
Aptos : Block-STM. Block-STM est un moteur d'exécution parallèle fondé sur la mémoire transactionnelle logicielle et un état multi-version, qui illustre une exécution optimiste transparente pour des transactions blockchain ordonnées.
Solana : Sealevel. Solana n'est pas un EVM, mais son runtime illustre un modèle différent dans lequel les transactions déclarent leurs accès aux comptes, ce qui permet d'ordonnancer en parallèle des travaux sans conflit.

Quelles sont les limites et les risques d'un EVM parallèle ?

L'exécution parallèle ne peut pas supprimer les dépendances inhérentes à l'état d'une application. Elle ajoute aussi une complexité d'ordonnancement, de validation, de mise en cache, de base de données et de réexécution qui doit être implémentée de manière cohérente sur l'ensemble des nœuds.

1. Un état sous contention réduit les gains de vitesse. Les transactions interagissant avec le même pool de liquidité, compteur global, valeur d'oracle ou emplacement de contrat très sollicité peuvent entrer en conflit et nécessiter une sérialisation ou une exécution répétée.

2. La spéculation peut gaspiller du calcul. Un worker optimiste peut achever une transaction à partir d'entrées périmées pour finalement écarter le résultat, ce qui accroît la charge CPU et mémoire lorsque le taux de conflits est élevé.

3. La complexité d'implémentation élargit la surface de bogues. Les ordonnanceurs, le stockage multi-version, la détection de conflits, la mise en cache et la logique de validation doivent reproduire exactement la sémantique de l'EVM pour les reverts, la comptabilisation du gas, les appels et les cas limites.

4. Les benchmarks peuvent ne pas représenter des charges de travail réelles. Le débit mis en avant pour des transferts indépendants peut surestimer les performances des applications où de nombreux utilisateurs cherchent à modifier un petit ensemble d'emplacements de stockage partagés.

5. Une capacité accrue peut augmenter les exigences des nœuds. Les réseaux doivent équilibrer CPU, mémoire, bande passante de stockage, conception de la base de données et croissance de l'état, afin que les objectifs de performance ne rendent pas la validation indépendante impraticable.

Un EVM parallèle modifie-t-il les résultats des contrats intelligents ?

Un EVM parallèle correctement implémenté ne modifie pas le résultat final défini par l'ordre des transactions du réseau. Le travail parallèle est provisoire, et le moteur valide ou réexécute les transactions afin que l'état final corresponde à la sémantique séquentielle requise. Les utilisateurs peuvent constater une capacité accrue ou une congestion moindre, mais les contrats doivent toujours observer les mêmes effets ordonnés. Cette garantie rend la gestion déterministe des conflits plus importante que la simple exécution de nombreux fils.