En résumé : Ce document de recherche fournit un aperçu des architectures de conception parallèle pour les blockchains, en utilisant trois exemples pertinents : Solana, Sei et Monad. Il met en évidence les différences entre la parallélisation optimiste et déterministe et examine les subtilités de l'accès à l'état et à la mémoire à travers ces chaînes.

Introduction

En 1837, l'informaticien et mathématicien Charles Babbage a conçu le “Moteur analytique, qui a posé les bases théoriques de la computation parallèle. Aujourd'hui, la parallélisation est un thème central dans le monde de la cryptographie alors que les blockchains tentent de repousser les limites du traitement, de l'efficacité et du débit.

L'Univers Parallèle

Le calcul parallèle permet à de nombreuses calculs ou processus d'être exécutés simultanément, par opposition aux calculs exécutés séquentiellement ou les uns après les autres. L'informatique parallèle désigne la division des problèmes plus importants en parties plus petites et indépendantes pouvant être exécutées par plusieurs processeurs communiquant via une mémoire partagée. Les systèmes parallèles présentent plusieurs avantages, tels qu'une efficacité et une vitesse accrues, une évolutivité, une fiabilité et une tolérance aux pannes améliorées, une meilleure utilisation des ressources et la capacité de traiter des ensembles de données très volumineux.

Cependant, il est crucial de reconnaître que l'efficacité de la parallélisation dépend des spécificités de l'architecture sous-jacente et de sa mise en œuvre. Deux goulots d'étranglement principaux pour les blockchains sont les fonctions cryptographiques (fonctions de hachage, signatures, courbes elliptiques, etc.) et l'accès à la mémoire/à l'état. Avec les blockchains, l'un des composants clés de la conception d'un système parallèle efficace réside dans les subtilités de l'accès à l'état. L'accès à l'état fait référence à la capacité d'une transaction à lire et écrire dans l'état d'une blockchain, y compris le stockage, les contrats intelligents et les soldes de compte. Pour qu'une blockchain parallélisée soit efficace et performante, l'accès à l'état doit être optimisé.

Il existe actuellement deux écoles de pensée sur l'optimisation de l'accès à l'état pour les blockchains parallélisées : la parallélisation déterministe par rapport à la parallélisation optimiste. La parallélisation déterministe nécessite que le code déclare explicitement à l'avance quelles parties de l'état de la blockchain seront accessibles et modifiées. Cela permet à un système de déterminer quelles transactions peuvent être traitées en parallèle sans conflits à l'avance. La parallélisation déterministe permet la prévisibilité et l'efficacité (surtout lorsque les transactions sont principalement indépendantes). Cependant, cela crée plus de complexité pour les développeurs.

La parallélisation optimiste ne nécessite pas que le code déclare l'accès à son état à l'avance et traite les transactions en parallèle comme s'il n'y avait pas de conflits. Si un conflit survient, la parallélisation optimiste réexécutera, retraitera ou exécutera séquentiellement les transactions en conflit. Bien que la parallélisation optimiste offre plus de flexibilité aux développeurs, une réexécution est nécessaire en cas de conflit, ce qui fait que cette méthode est la plus efficace lorsque les transactions ne sont pas en conflit. Il n'y a pas de réponse correcte quant à laquelle de ces approches est meilleure. Ce sont simplement deux approches différentes (et viables) de la parallélisation.

Dans la première partie de cette série, nous explorerons d'abord quelques notions de base des systèmes parallèles non crypto, suivies de l'espace de conception pour l'exécution parallèle des blockchains, en mettant l'accent sur trois domaines principaux :

1. Aperçu des systèmes parallèles de cryptographie
2. Approches d'Accès à la Mémoire & à l'État
3. Opportunités de conception parallèle

Systèmes Parallèles Non-Crypto

En tenant compte de ce que nous venons de lire ci-dessus sur ce que permet la computation parallèle et les avantages des systèmes parallèles, il est facile de comprendre pourquoi l'adoption de la computation parallèle a pris son envol ces dernières années. L'adoption accrue de l'informatique parallèle a permis de nombreuses percées rien que ces dernières décennies.

1. Imagerie médicale: Le traitement parallèle a fondamentalement transformé l'imagerie médicale, entraînant des augmentations significatives de vitesse et de résolution dans diverses modalités telles que l'IRM, la TDM, les rayons X et la tomographie optique. Nvidia est à l'avant-garde de ces avancées, offrant aux radiologues des capacités améliorées d'intelligence artificielle grâce à sa trousse à outils de traitement parallèle, qui permet aux systèmes d'imagerie de gérer de manière plus efficace des charges de données et de calcul accrues.
2. Astronomie: Certains nouveaux phénomènes, comme la compréhension des trous noirs, n'ont été rendus possibles que grâce à l'utilisation de supercalculateurs parallèles.
3. Le moteur de jeu Unity : Le moteur de Unity utilise les capacités des GPU, conçus pour des charges de travail graphiques massives, pour améliorer les performances et la vitesse. Le moteur est équipé de fonctionnalités de traitement multithread et parallèle, offrant une expérience de jeu fluide et créant des environnements de jeu complexes et détaillés.

Examinons trois blockchains qui ont mis en place des environnements d'exécution parallèles. Tout d'abord, nous allons décortiquer Solana, suivi de deux chaînes basées sur EVM, Monad et Sei.

Aperçu de la conception parallèle - Solana

À un niveau élevé, la philosophie de conception de Solana est que l'innovation en matière de blockchain devrait évoluer avec les progrès matériels. À mesure que le matériel s'améliore avec le temps grâce à la loi de Moore, Solana est conçu pour bénéficier de performances et de scalabilité accrues. Co-Fondateur de Solana Anatoly Yakovenkoinitialement conçuL'architecture de parallélisation de SolanaIl y a plus de cinq ans, et aujourd'hui, le parallélisme en tant que principe de conception de la blockchain se répand rapidement.

Solana utilise la parallélisation déterministe, qui provient de l'expérience passée d'Anatoly dans le domaine des systèmes embarqués, où vous déclarez généralement tout l'état au préalable. Cela permet au processeur de connaître toutes les dépendances, ce qui lui permet de précharger les parties nécessaires de la mémoire. Le résultat est une exécution optimisée du système, mais cela nécessite encore que les développeurs fassent un travail supplémentaire au préalable. Sur Solana, toutes les dépendances en mémoire pour un programme sont requises et déclarées dans la transaction construite (c'est-à-dire les listes d'accès), ce qui permet au runtime de planifier et d'exécuter efficacement de multiples transactions en parallèle.

Le prochain composant majeur de l'architecture de Solana est le Sealevel VM, qui est l'exécution parallèle des contrats intelligents de Solana. Sealevel prend en charge nativement le traitement multiple de contrats et de transactions en parallèle en fonction du nombre de cœurs qu'un validateur possède. Un validateur dans une blockchain est un participant du réseau chargé de vérifier et de valider les transactions, de proposer de nouveaux blocs et de maintenir l'intégrité et la sécurité de la blockchain. Comme les transactions déclarent quels comptes doivent être lus et écrits bloqués à l'avance, l'ordonnanceur de Solana est capable de déterminer quelles transactions peuvent être exécutées simultanément. En conséquence, en matière de validation, le « Producteur de Bloc » ou Leader est capable de trier des milliers de transactions en attente et de planifier les transactions non chevauchantes en parallèle.

L'élément de conception final pour Solana est le « pipelining ». Le pipelining se produit lorsque les données doivent être traitées en une série d'étapes, et que du matériel différent est responsable de chacune d'elles. L'idée clé ici est de prendre les données qui doivent être exécutées séquentiellement et de les paralléliser en utilisant le pipelining. Ces pipelines peuvent être exécutés en parallèle, et chaque étape du pipeline peut traiter différents lots de transactions.

Ces optimisations permettent à Sealevel d'organiser et d'exécuter simultanément des transactions indépendantes, en utilisant la capacité matérielle de traiter plusieurs points de données à la fois avec un seul programme. Sealevel trie les instructions par programID et exécute la même instruction sur tous les comptes pertinents en parallèle.

Avec ces innovations à l'esprit, nous pouvons voir que Solana a été intentionnellement conçu pour prendre en charge la parallélisation.

Vue d'ensemble de la conception parallèle - Sei

Sei est une blockchain de couche 1 open-source et polyvalente spécialisée dans l'échange d'actifs numériques. Sei V2 tire parti de la parallélisation optimiste et, par conséquent, est plus convivial pour les développeurs que son homologue déterministe. En parallélisation optimiste, les contrats intelligents peuvent être exécutés de manière plus transparente et simultanée sans que les développeurs aient à déclarer leurs ressources à l'avance. Cela signifie que la chaîne exécute de manière optimiste toutes les transactions en parallèle. Cependant, en cas de conflits (c'est-à-dire, de multiples transactions accédant au même état), la blockchain suivra le composant de stockage spécifique que chaque transaction conflictuelle impacte.

Les approches de blockchain de Sei exécutent des transactions en utilisant le "contrôle de concurrence optimiste (OCC)." Le traitement de transactions concurrentes se produit lorsque plusieurs transactions sont simultanément actives dans un système. Il existe deux phases dans cette approche de transaction : l'exécution et la validation.

Dans la phase d'exécution, les transactions sont traitées de manière optimiste, avec toutes les lectures/écritures temporairement stockées dans un magasin spécifique à la transaction. Après cela, chaque transaction entrera dans la phase de validation, où les informations dans les opérations de magasin temporaire sont vérifiées par rapport à tout changement d'état effectué par les transactions précédentes. Si une transaction est indépendante, la transaction s'exécute en parallèle. Si une transaction lit des données modifiées par une autre transaction, cela créerait un conflit. Le système parallèle de Sei identifiera chaque conflit en comparant les ensembles de lectures des transactions par rapport aux derniers changements d'état dans un magasin multi-version (ceux-ci sont indexés par ordre de transaction). Sei réexécutera et révalidera les instances où des conflits surviennent. Il s'agit d'un processus itératif impliquant l'exécution, la validation et la réexécution afin de résoudre les conflits. Le graphique ci-dessous illustre l'approche de Sei vis-à-vis des transactions lorsqu'un conflit survient.

Source : https://blog.sei.io/sei-v2-le-premier-evm-parallélisé/

L'implémentation de Sei se traduit par des frais de gaz moins chers et un espace de conception plus large pour les développeurs EVM. Historiquement, les environnements EVM ont été limités à <50 TPS, ce qui a forcé les développeurs à créer des applications qui suivaient des anti-patterns. Sei V2 permet aux développeurs d'aborder des secteurs qui nécessitent généralement des performances élevées et des frais réduits, comme DeFi, DePIN et Gaming.

Vue d'ensemble de la conception parallèle - Monad

Monad construit une couche EVM parallèle Layer 1 avec une compatibilité complète du bytecode. Ce qui rend Monad unique n'est pas seulement son moteur de parallélisation, mais ce qu'ils ont construit sous le capot pour l'optimiser. Monad adopte une approche unique de sa conception globale en incorporant plusieurs fonctionnalités clés, notamment le pipelining, l'E/S asynchrone, la séparation du consensus et de l'exécution, et MonadDB.

Une innovation clé dans la conception de Monad est pipeliningavec un léger décalage. Le décalage permet de paralléliser davantage de processus en exécutant plusieurs instances simultanément. Par conséquent, le pipelining est utilisé pour optimiser un certain nombre de fonctions, telles que le pipelining de l'accès à l'état, le pipelining de l'exécution des transactions, le pipelining au sein du consensus et de l'exécution, et le pipelining au sein du mécanisme de consensus lui-même.

Ensuite, nous allons double-cliquer sur la pièce de parallélisation de Monad. Dans Monad, les transactions sont ordonnées de manière linéaire au sein du bloc, mais l'objectif est d'atteindre cet état final plus rapidement en exploitant l'exécution parallèle. Monad utilise un algorithme de parallélisation optimiste pour la conception de son moteur d'exécution. Le moteur de Monad traite les transactions simultanément puis effectue une analyse pour s'assurer que le résultat serait identique si les transactions étaient exécutées l'une après l'autre. En cas de conflits, vous devez re-exécuter. L'exécution parallèle ici est un algorithme relativement simple, mais le combiner avec les autres innovations clés de Monad est ce qui rend cette approche novatrice. À noter que même en cas de re-exécution, c'est généralement peu coûteux car les entrées nécessaires pour une transaction invalide resteront presque toujours dans le cache, ce qui en fera une simple recherche dans le cache. La re-exécution est garantie de réussir car vous avez déjà exécuté les transactions précédentes dans le bloc.

Monad améliore également les performances en séparant l'exécution et le consensus, à l'instar de Solana et Sei, en plus de l'exécution différée. L'idée ici est que si vous relâchez la condition pour que l'exécution soit terminée au moment où le consensus est complet, vous pouvez exécuter les deux en parallèle, ce qui donne du temps supplémentaire pour les deux. Bien sûr, Monad utilise un algorithme déterministe pour gérer cette condition afin de garantir qu'une de ces tâches ne prenne pas trop d'avance sans possibilité de rattraper.

Approches uniques pour l'accès à l'état & à la mémoire

Comme je l'ai mentionné au début de ce post, l'accès à l'état est l'un des goulets d'étranglement typiques en termes de performances pour les blockchains. Les choix de conception concernant l'accès à l'état et à la mémoire peuvent finalement dicter si une implémentation spécifique d'un système parallèle améliorera les performances en pratique. Ici, nous allons analyser et comparer les différentes approches prises par Solana, Sei et Monad.

Accès à l'état de Solana : AccountsDB / Cloudbreak

Solana utilise une mise à l'échelle horizontale pour distribuer et gérer les données d'état sur plusieurs appareils SSD. De nombreuses blockchains utilisent aujourd'hui des bases de données génériques (c'est-à-dire LevelDB) avec des limitations sur la gestion d'un grand nombre de lectures et d'écritures concurrentes de données d'état. Pour éviter cela, Solana a construit son propre compteDB personnalisé en tirant partiCloudbreak.

Cloudbreak est conçu pour un accès parallèle à travers des opérations d'E/S plutôt que de se fier uniquement à la RAM, qui est intrinsèquement rapide. Les opérations d'E/S (Entrée/Sortie) désignent la lecture de données depuis ou l'écriture de données vers une source externe, telle qu'un disque, un réseau ou un périphérique. Initialement, Cloudbreak utilisait un index en RAM pour mapper les clés publiques aux comptes détenant des soldes et des données. Cependant, au moment de la rédaction de ce document et de la version 1.9, l'index a été déplacé hors de la RAM et sur des SSD. Ce changement permet à Cloudbreak de traiter simultanément 32 opérations d'E/S dans sa file d'attente, améliorant le débit à travers plusieurs SSD. Par conséquent, les données de la blockchain telles que les comptes et les transactions peuvent être accessibles de manière efficace, comme s'ils étaient en RAM en utilisant des fichiers mappés en mémoire. Le graphique ci-dessous représente une hiérarchie de mémoire illustrative. Bien que la RAM soit plus rapide, elle a moins de capacité que les SSD et est généralement plus chère:

Diagramme illustratif de la hiérarchie de la mémoire

En mettant à l'échelle horizontalement et en distribuant les données d'état sur plusieurs appareils, Cloudbreak réduit la latence et améliore l'efficacité, la décentralisation et la résilience du réseau au sein de l'écosystème Solana.

Accès à Six États: SeiDB

Sei a repensé son stockage, SeiDB, pour résoudre plusieurs problèmes : amplification de l'écriture (combien de métadonnées sont nécessaires pour maintenir des structures de données, plus petites = mieux), l'enflure de l'état, les opérations lentes et la dégradation des performances avec le temps. Le nouveau redisgn est maintenant divisé en deux composants : le magasin d'état et l'engagement d'état. L'enregistrement et la vérification de tout changement apporté aux données sont gérés par l'engagement d'état, tandis que la base de données qui conserve un compte de toutes les données à tout moment est gérée par le stockage d'état (SS).

Dans Sei V2, l'engagement d'État utilise une mémoire mappée Architecture de l'arbre IAVL (MemIAVL). L'arbre IAVL mappé en mémoire stocke moins de métadonnées, ce qui réduit le stockage d'état et les temps de synchronisation d'état et rend l'exécution d'un nœud complet beaucoup plus facile. L'arbre IAVL mappé en mémoire est représenté par trois fichiers sur le disque (kv, branche, feuilles); par conséquent, moins de métadonnées doivent être suivies, ce qui aide à réduire le stockage d'état de plus de 50%. La nouvelle structure MemIAVL aide à réduire le facteur d'amplification d'écriture car elle réduit les métadonnées nécessaires pour maintenir les structures de données.

La mise à jour de SeiDB permet un support flexible de la base de données backend pour la couche de stockage d'état. Sei estime que les différents opérateurs de nœuds auront des besoins et des exigences de stockage diversifiés. Par conséquent, le SS a été conçu pour accueillir différents backends, offrant aux opérateurs la liberté et la flexibilité, c'est-à-dire PebbleDB, RocksDB, SQLite, etc.

Accès à l'état : MonadDB

Il existe quelques nuances importantes pour l'accès à l'état de Monad. Tout d'abord, la plupart des clients Ethereum utilisent deux types de bases de données : des bases de données B-Tree (c'est-à-dire LMDB) ou des bases de données de fusion structurée par journal (LSM) (c'est-à-dire RocksDB, LevelDB). Les deux sont des structures de données génériques qui ne sont pas explicitement conçues pour les blockchains. De plus, ces bases de données ne tirent pas parti des avancées les plus récentes de la technologie Linux, en particulier en ce qui concerne les opérations asynchrones et les optimisations I/O. Enfin, Ethereum lui-même gère l'état en utilisant Patricia Merkle Trie, qui se spécialise dans la cryptographie, la vérification et les preuves. Le principal problème est que les clients doivent intégrer ce Trie spécifique de Patricia Merkle dans des bases de données plus génériques (c'est-à-dire, B-Tree / LSM), avec des inconvénients de performance significatifs tels qu'un accès excessif au disque.

Tout ce qui précède contribue à expliquer pourquoi Monad a décidé de créer sa base de données personnalisée MonadDB, spécialement conçue pour gérer plus efficacement les données et l'accès à l'état de la blockchain. Certaines des principales caractéristiques de MonadDB incluent une base de données à accès parallèle, une base de données personnalisée optimisée pour les données de Merkle Trie, un accès à l'état efficace par rapport à l'utilisation standard de la RAM, ainsi que la décentralisation et la scalabilité.

MonadDB est spécifiquement conçu pour les blockchains, ce qui le rend plus performant que l'utilisation de bases de données génériques. Le MonadDB personnalisé est spécialisé et conçu pour gérer efficacement les données de type arbre de Merkle, permettant un accès parallèle à plusieurs nœuds d'arbre en même temps. Bien que le coût d'une seule lecture sur MonadDB par rapport à certaines des bases de données génériques énumérées ci-dessus soit le même, la propriété clé ici est que MonadDB peut exécuter de nombreuses lectures en parallèle, ce qui entraîne une accélération massive.

MonadDB permet un accès simultané à l'état de la base de données à accès parallèle. Étant donné que Monad construit cette base de données à partir de zéro, il est capable de tirer parti des technologies de noyau Linux les plus récentes et de la pleine puissance des SSD pour les E/S asynchrones. Avec les E/S asynchrones, si une transaction nécessite la lecture d'un état à partir du disque, cela ne devrait pas arrêter les opérations en attente de leur achèvement. Au lieu de cela, il devrait commencer la lecture et continuer simultanément à traiter d'autres transactions. C'est ainsi que les E/S asynchrones accélèrent considérablement le traitement pour MonadDB. Monad est capable d'extraire de meilleures performances du matériel en optimisant l'utilisation des SSD et en réduisant la dépendance à une RAM excessive. Cela a l'avantage supplémentaire de s'aligner sur la décentralisation et la scalabilité.

Résumé des comparaisons pour Solana vs Sei vs Monad

Conclusion

En conclusion, explorer la parallélisation dans les blockchains à travers le prisme de Solana, Sei et Monad offre une compréhension complète de la manière dont différentes architectures et approches peuvent améliorer les performances et la scalabilité. La parallélisation déterministe de Solana, avec son accent sur la déclaration préalable de l'accès à l'état, offre une prévisibilité et une efficacité, en en faisant un choix puissant pour les applications nécessitant un débit élevé. D'un autre côté, l'approche de parallélisation optimiste de Sei privilégie la flexibilité des développeurs et convient parfaitement aux environnements où les conflits de transactions sont rares. Avec son mélange unique de parallélisation optimiste et de MonadDB personnalisé, Monad présente une solution innovante qui exploite les dernières avancées technologiques pour optimiser l'accès à l'état et les performances.

Chaque blockchain présente une approche distincte pour relever les défis de la parallélisation, avec son propre ensemble de compromis. La conception de Solana vise à maximiser l'utilisation du matériel et le débit, tandis que Sei se concentre sur la facilitation du processus de développement, et Monad met l'accent sur une solution de base de données sur mesure pour les données de la blockchain. Ces différences mettent en évidence la diversité de l'écosystème blockchain et l'importance de choisir la bonne plateforme en fonction des besoins spécifiques de l'application.

Alors que l'espace de la blockchain continue d'évoluer, les avancées dans les techniques de parallélisation démontrées par Solana, Monad et Sei inspireront sans aucun doute davantage d'innovations. Le chemin vers des blockchains plus efficaces, évolutives et conviviales pour les développeurs est en cours, et les leçons tirées de ces plateformes joueront un rôle crucial dans la définition de l'avenir de la technologie blockchain.

Dans la deuxième partie de cette série, nous plongerons dans les implications économiques et les compromis associés à ces systèmes de conception parallèle.

Avertissement：

1. Cet article est repris de [ Reciprocal Ventures], Tous les droits d'auteur appartiennent à l'auteur original [Ali Sheikh]. Si des objections sont formulées à cette réimpression, veuillez contacter le Porte Apprendreéquipe, et ils s'en occuperont rapidement.
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 aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe Gate Learn. Sauf mention contraire, copier, distribuer ou plagier les articles traduits est interdit.