Imaginez ceci : vous êtes dans une cuisine occupée où les chefs doivent attendre que l'un finisse de couper les légumes avant que l'autre puisse commencer à faire cuire les pommes de terre. Cela semble frustrant, lent et inefficace, n'est-ce pas ? C'est ce que représente l'exécution synchrone en informatique et en blockchain : une tâche doit être terminée avant que la suivante ne puisse être commencée. Maintenant, imaginez une cuisine bien coordonnée où chaque chef travaille sur différentes parties de plusieurs plats simultanément, préparant les ingrédients, cuisinant et dressant tout en même temps. C'est l'exécution asynchrone - les tâches s'exécutent simultanément, créant un flux de travail plus efficace et plus rapide.

Au carrefour de l'évolution de la blockchain, la composabilité synchrone est devenue un mot à la mode car elle semble offrir une solution pour unir les rollups fragmentés de la couche 2 sur le réseau Ethereum. Cette approche répond à l'expérience utilisateur désastreuse et au DevEx où même un simple transfert entre les couches 2 pourrait coûter cher et prendre jusqu'à 7 jours.L'implication de VitalikCes débats mettent en évidence que la synchronicité universelle n'est pas nécessairement une condition préalable à la résolution de ces problèmes. Nous sommes d'accord sur le fait qu'une exécution de traduction efficace n'a pas besoin d'impliquer la synchronicité, et qu'il y a des coûts réels liés à la construction et à la maintenance d'une infrastructure synchrone. Nous pensons qu'il ne s'agit pas d'un choix binaire entre tout étant synchrone ou asynchrone. Les deux peuvent coexister de manière ad hoc, avec un probable basculement vers ce dernier.

1. Décomposable asynchrone

Dans la recherche de performances à grande échelle dans la technologie de la blockchain, l'exécution parallèle de contrats intelligents individuels a suscité une attention considérable. Traditionnellement, les performances de chaque contrat intelligent ont été limitées par les capacités d'une seule machine virtuelle (EVM), même avec l'avènement de systèmes multi-chaînes ou de la couche 2. Les machines virtuelles parallèles offrent une solution prometteuse, permettant l'exécution concurrente de transactions d'un seul contrat intelligent, exploitant ainsi davantage de cœurs de CPU pour des performances améliorées.

L'architecture distribuée d'exécution de relais parallèle (PREDA) est un modèle de programmation distribué, fonctionnel, orienté vers la portée et de haut niveau, conçu pour les contrats intelligents généraux intrinsèquement parallélisés sur des systèmes de blockchain multi-EVM distribués. D'un point de vue système, PREDA rend les EVM parallèles décomposables et asynchrones, permettant la pleine parallélisation d'une fonction de contrat et maximisant la concurrence d'un ensemble de transactions. Cela garantit que toutes les instances d'EVM peuvent être principalement utilisées, atteignant des performances et une évolutivité optimales.

Avant de plonger dans les détails, clarifions d'abord à quoi se réfèrent plusieurs termes clés dans cette pièce :

Tx1= Transaction 1

Tx2= Transaction 2

Nous supposons que,

L'exécution de Tx1 nécessite de changer l'état A, l'état B, l'état C

L'exécution de Tx2 doit modifier l'état A, l'état D, l'état E

Les méthodes de parallélisation de pointe pour les EVM¹, telles que celles mises en œuvre par Sei, Aptos et Sui, tentent d'exécuter toutes les étapes de chaque transaction de manière synchrone. Imaginez que vous zoomez sur une seule scène de transaction, dans ces systèmes une transaction est exécutée dans une hauteur de bloc, indépendamment de la nature des dépendances de données dispersées (c'est-à-dire l'accès à différentes parties de l'état du contrat). En conséquence, si une étape des états de contrat consultés est partagée ou mise à jour entre deux transactions, elles sont identifiées comme des conflits de lecture-écriture ou écriture-écriture et ne peuvent pas être exécutées en parallèle, ce qui entrave le débit global et la scalabilité du système. Cette situation s'aggrave considérablement lorsque l'activité on-chain augmente soudainement.

PREDA adopte une approche nouvelle et différente des systèmes mentionnés ci-dessus. Il adopte un modèle d'exécution de contrat intelligent qui met en œuvre une décomposabilité asynchrone, où les étapes d'une transaction sont décomposées en fonction de leurs dépendances d'accès aux données, permettant l'exécution asynchrone des étapes. Le modèle d'exécution de PREDA permet d'obtenir une efficacité accrue et une évolutivité théoriquement infinie. Nous approfondirons la manière dont PREDA y parvient et présenterons des résultats expérimentaux pour étayer cette affirmation.

2. Évaluation des performances

Les transactions de transfert de jetons ETH historiques sont rejouées pour évaluer Sei (V2), Aptos, Sui et PREDA, en termes de débit et de scalabilité. Notez que notre évaluation utilise de véritables transactions historiques de transfert de jetons ETH du monde réel au lieu de créer un ensemble de transactions de transfert entre des paires aléatoires d'adresses. Les transactions aléatoires produiront un résultat expérimental excessif par rapport aux performances dans les cas réels, car les transactions du monde réel impliquent des adresses qui sont liées d'une manière ou d'une autre, ce qui introduit une grande quantité de dépendances de données.

Les configurations expérimentales sont les suivantes :

La comparaison dans la Figure 1 souligne la nécessité d'adopter le modèle de programmation PREDA pour réaliser des améliorations significatives de débit. PREDA démontre un TPS 3,3 à 28,2 fois plus élevé que Aptos pour de véritables transactions de transfert historiques sur le réseau Ethereum.

Étant donné que ces systèmes sont implémentés dans différentes langues (y compris Go, Rust et C++) et différentes machines virtuelles, nous évaluons l'évolutivité des différents systèmes en fonction de l'accélération relative par rapport à la base de l'utilisation d'un seul EVM, afin d'exclure l'impact des différentes implémentations du système.

Figure 1. Les chiffres absolus de débit en TPS des contrats intelligents de transfert de jetons équivalents exécutés sur Sei, Aptos, Sui et PREDA

Figure 2. Accélérations relatives pour Aptos, Sui, Sei et PREDA par rapport à leurs propres bases

3. Le modèle de programmation

Pour faciliter la compréhension de PREDA pour toute personne familière avec l'EVM parallèle, il existe deux types typiques de mécanismes de parallélisation dans les systèmes de blockchain EVM parallèles d'aujourd'hui¹.

• La parallélisation optimiste, y compris Aptos, Sei (V2) et Monad, ignore les dépendances d'état entre les transactions, exécute et valide les transactions de manière concurrente, et annule une transaction pour une nouvelle exécution en cas de conflit.
• La parallélisation pessimiste, y compris Solana (Sealevel), Sui et Sei (V1), vérifie préalablement les dépendances d'état pour chaque transaction avant l'exécution, analyse leurs dépendances d'état et exécute simultanément uniquement ces transactions sans conflit.

Les deux méthodes suivent l'architecture Shared-everything et considèrent une transaction dans son ensemble dans le contrôle de la concurrence ; toutes les étapes (par exemple, l'accès à différents états de contrat) ne sont pas décomposables et doivent être exécutées de manière synchrone. Le modèle PREDA propose @devteam_48518/crystality-le-modèle-evm-parallèle-implementant-l'architecture-shared-nothing-8d82fc0a836a">Architecture Shared-nothing pour rompre les dépendances d'état et garantir que différentes instances EVM n'accéderont jamais à la même partie de l'état du contrat, évitant ainsi tout conflit d'écriture.

Au cœur de PREDA, on retrouve des Scopes de Contrat Programmables qui décomposent l'état du contrat en morceaux non superposables et parallélisables avec une granularité fine, ainsi qu'un Relais Fonctionnel Asynchrone pour décrire la commutation du flux d'exécution entre différents EVM.

Pour expliquer plus en détail ce que signifient ces concepts, dans PREDA, une fonction de contrat est décomposée en plusieurs étapes ordonnées, chacune reposant sur un seul morceau parallélisable de l'état sans conflits. Une transaction initiée par l'utilisateur est d'abord dirigée vers un EVM qui détient les états de l'adresse de l'utilisateur de manière déterministe, par exemple en utilisant une méthode de mappage de l'adresse de l'utilisateur à l'EVM. Pendant l'exécution de la transaction, le flux d'exécution peut passer d'un EVM à un autre qui détient les états de contrat souhaités en émettant une transaction de relais. De cette manière, PREDA maintient les données immobiles tout en déplaçant le flux d'exécution autour des EVM selon les dépendances des données.

À chaque EVM, les transactions initiées par l'utilisateur et les transactions de relais sont ordonnées et exécutées séquentiellement, tandis que les transactions sur différentes EVM sont exécutées simultanément car il n'y a pas de dépendances de données entre les EVM. Ce mécanisme évite la réexécution liée aux conflits dans les méthodes basées sur la parallélisation optimiste et les coûts d'analyse des dépendances de l'état à l'exécution et de verrouillage/déverrouillage dans les approches basées sur la parallélisation pessimiste. Par conséquent, PREDA offre une architecture parallèle et sans partage pour les systèmes de blockchain, qui diffère de l'architecture séquentielle et tout-partage à la fois de Solidity et Move, ce qui peut entraîner un surcoût significatif de contrôle de la concurrence.

4. La langue

Nous avons implémenté le modèle de programmation PREDA sous forme de langage semblable à Algo, similaire à C/C++ et Javascript. Ce qui suit est une fonction de transfert de jetons simplifiée en Solidity et dans le langage PREDA.

Le code Solidity de la figure (a) comporte un état de contrat (soldes) représentant les soldes d'adresses et une fonction de transfert pour transférer un montant spécifié de jetons de l'expéditeur de la transaction (msg.sender) à un destinataire (payee).

Dans la mise en œuvre PREDA présentée à la figure (b), le mot-clé @adressedéfinit des portées de contrats programmables, où les états de contrat appartenant à une variable de contrat (solde) sont partitionnés par adresse, dispersés et gérés par les EVM. Le mot-clé relais identifie un relais fonctionnel asynchrone.

Il y a trois parties dans la mise en œuvre de PREDA. Dans la partie (1), le mot-clé @addressdéfinit les soldes des utilisateurs, fournissant une description d'état fine et séparable. La variable d'étendue d'adresse balance a une instance unique pour chaque adresse d'utilisateur. Les instances de différentes adresses d'utilisateur sont accessibles et maintenues par des EVM différentes non chevauchantes. La fonction de transfert est définie dans la même étendue d'adresse dans la partie (2), invoquée en fournissant l'adresse du payeur en tant qu'étendue cible lors de l'initialisation d'une transaction de transfert par un utilisateur. Dans la partie (3), pour procéder au dépôt vers le bénéficiaire après un retrait réussi, un relais est initié avec l'adresse du bénéficiaire en tant qu'étendue cible, ajoutant des fonds au solde du bénéficiaire et exécuté par une EVM qui héberge l'instance de solde de l'adresse du bénéficiaire.

Le flux d'exécution d'une transaction de transfert de jetons dans PREDA

La figure ci-dessus montre le flux d'exécution d'une transaction de transfert de jetons dans le système EVM parallèle de PREDA. Bob lance une transaction pour appeler la fonction de transfert, qui sera dirigée vers l'EVM qui détient le solde de Bob et le retrait est exécuté là-bas. Après cela, une transaction de relais est émise et dirigée vers l'EVM qui détient le solde d'Alice et le dépôt est exécuté. La parallélisation se produit de deux manières :

1. Entre transactions initiées par l'utilisateur : Étant donné que les états partitionnés par adresse ne se chevauchent pas, les transactions initiées par l'utilisateur peuvent être exécutées simultanément sans conflit. Par exemple, dans le contrat de transfert de jetons qui met à jour l'état du payeur par adresse, différentes transactions initiées par l'utilisateur peuvent être parallélisées à travers les EVM.
2. Avec les transactions de relais : Dans un scénario où Bob transfère des jetons à Alice et Carol, la transaction de relais pour le dépôt à Alice (du transfert de Bob à Alice) peut être exécutée simultanément avec la transaction initiée par l'utilisateur pour le retrait de Bob (dans le transfert de Bob à Carol) et le dépôt à Carol. Seulement avec la décomposabilité du modèle PREDA, la parallélisation inhérente dans un contrat intelligent peut être exposée au système de blockchain sous-jacent, permettant aux transactions initiées par l'utilisateur et de relais d'être traitées de manière pipelinée, facilitant l'exécution parallèle.

Suivant et au-delà

PREDA marque une avancée majeure dans les performances de la blockchain et, plus important encore, dans la scalabilité. En mettant en œuvre la décomposabilité asynchrone, elle permet un traitement efficace des transactions sans les goulots d'étranglement des modèles de parallélisation synchrone conventionnels. Cette approche décompose les transactions en micro-transactions selon les dépendances des données, permettant des changements d'état simultanés et évitant complètement les conflits d'écriture.

La généralité de PREDA va au-delà de l'utilisation de @adressepartitionner les états de contrat par adresse. Il permet des types de partition personnalisés avec des mots-clés comme @type, où le type peut être n'importe quel nom élémentaire Solidity tel que @uint. De plus, PREDA prend en charge les états de contrat non partitionnés avec @globalen veillant à ce que chaque EVM maintienne des valeurs cohérentes pour de tels états. Cette flexibilité dans la partition des états améliore l'adaptabilité et l'efficacité du modèle pour des contrats intelligents diversifiés.

Nos expériences démontrent que PREDA surpasse significativement les autres méthodes de parallélisation, offrant un débit et une évolutivité plus élevés. Les prochains articles de l'équipe PREDA approfondiront nos résultats, en offrant des comparaisons plus complètes avec divers types de contrats intelligents et des analyses approfondies du modèle et du langage de programmation PREDA. Restez à l'écoute pour ces explorations détaillées.

Avertissement :

1. Cet article est un repost de [Medium]. Les droits d'auteur appartiennent à l'auteur original, [PREDA Parallel VMs]. Si vous avez des objections concernant cette republication, veuillez contacter legate Équipe d'apprentissage. L'équipe traitera rapidement vos préoccupations conformément aux procédures pertinentes.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. L'équipe Learn de gate a traduit l'article dans d'autres langues. La copie, la distribution ou le plagiat des articles traduits est interdit sauf mention contraire.