Transféré le Titre Original: Designer Blockspace: L'Avenir des Environnements d'Exécution

Au cours des neuf années écoulées depuis le lancement d'Ethereum, le premier blockchain décentralisé et programmable, la cryptographie a rencontré plusieurs obstacles dans sa quête de mise à l'échelle des applications décentralisées pour des milliards d'utilisateurs. Et afin de développer des solutions de mise à l'échelle pour y remédier, l'industrie de la cryptographie a continuellement financé et développé de tout nouveaux types de blockchains pour résoudre le "problème de performance".

Cependant, le "problème de performance" a été mal défini et quantifié. Des mèmes synthétiques tels que "transactions par seconde" ont soigneusement emballé ce qui sont en réalité des comparaisons entre pommes et oranges entre des transactions qui ne nécessitent pas un travail computationnel équivalent. Le manque de nuances dans ces indicateurs masque également notre capacité à évaluer les impacts indépendants des composants d'une blockchain sur les performances, nous détournant d'une approche fondée pour identifier les ensembles d'optimisations que nous pouvons apporter à la résolution de problèmes hautement interdépendants.

Malgré ce brouillard, nous avons vu des améliorations crédibles et durables de la scalabilité de la blockchain se dérouler au cours des dernières années. Alors qu'Ethereum avance dans sa feuille de route centrée sur les rollups, une nouvelle vague de rollups, coprocesseurs, disponibilité des données (DA) couches, et des L1 concurrents émergent – chacun avec des choix de conception uniques pour fournir aux développeurs des environnements plus performants pour construire des dapps évolutifs et conviviaux.

Aujourd'hui, l'introduction de l'EIP4844 et des couches DA alternatives a permis de soulager le goulot d'étranglement critique de la DA. Malgré cette étape cruciale, des preuves suggèrent que d'autres goulots d'étranglement importants doivent être résolus. Le mois dernier, Basecollecté1,57 million de dollars de frais de transaction en une seule journéetout en ne payant que 5 000 $ de frais de disponibilité des données à Ethereum. Cela suggère que le travail de calcul nécessaire pour valider et traiter les mises à jour de l'état reste un goulot d'étranglement critique et une opportunité d'amélioration.

Cet article évaluera les choix de conception faits par les environnements d'exécution intégrés et modulaires dans leur démarche visant à résoudre le problème des performances accrues et à étendre le champ d'application des applications pouvant vivre onchain.

Défis d'aujourd'hui

La performance d'une couche d'exécution peut être évaluée en fonction du travail de calcul que réalisent les nœuds d'exécution par rapport au temps de bloc de leurs chaînes, ou du "gaz calculé par seconde."

Avec cela à l'esprit, nous pouvons réduire les goulots d'étranglement de la couche d'exécution à deux facteurs interconnectés : l'accès à l'état inefficace et le calcul inefficace.

L'accès inefficace à l'état fait référence aux frais généraux liés à la récupération et à la mise à jour de l'état de la blockchain, ce qui peut ralentir le traitement des transactions. D'autre part, la computation inefficace est une fonction des frais généraux engendrés par les algorithmes exécutant des opérations et des transitions d'état, qui peuvent inclure tout, des simples transferts aux contrats intelligents complexes et aux vérifications de signature.

Ces goulots d'étranglement se renforcent mutuellement : les retards dans l'accès à l'état peuvent prolonger le temps de calcul, tandis que des pratiques de calcul inefficaces peuvent solliciter la gestion de l'état. De plus, les améliorations proposées pour traiter ces problèmes nécessitent souvent des améliorations systémiques telles que le sharding ou l'adoption d'architectures sans état, qui améliorent l'accès à l'état et l'efficacité du calcul pour améliorer les performances d'exécution.

Bottleneck #1: Accès inefficace à l'état

Le coût et la vitesse nécessaires pour accéder à l'état d'une blockchain sont des goulots d'étranglement critiques pour des environnements d'exécution performants et peuvent être réduits à la question de l'engorgement de l'état.

Dans les blockchains, l'état du monde est géré et mis à jour à travers des structures de données spécifiques appelées arbresLes arbres sont indispensables aux blockchains, fournissant un moyen sécurisé et efficace de donner aux parties externes au nœud exécutant des garanties autour de l'état correct de la blockchain. Chaque mise à jour dans un trie génère un nouveau hachage de racine, que les clients légers peuvent référencer pour vérifier les transactions et les soldes des comptes sans avoir à conserver l'ensemble de la chaîne.

Ethereum repose spécifiquement sur une structure de données connue sous le nom de trie de Merkle Patricia (MPT), qui se compose @chiqing/merkle-patricia-trie-explained-ae3ac6a7e123">quatre sous-arbres.

À mesure qu'Ethereum ajoute plus de contrats intelligents et de jetons à son état, son arbre d'état devient plus grand et plus complexe. À mesure que l'état grandit, il nécessite plus d'espace de stockage, plus de ressources computationnelles pour le traitement, et plus de bande passante pour transmettre. En même temps, les contraintes matérielles du nœud restent à peu près les mêmes.

Cette croissance de l'état a un impact direct sur les performances d'Ethereum car l'état est stocké sur le disque et les opérations sur disque entraînent un surcoût élevé. Alors qu'accéder aux données depuis un registre CPU peut prendre 0,1 nanoseconde, cela peut prendre entre 10 et 100 microsecondes.(100x–1000x plus lent)pour accéder aux données d'un disque, ce qui équivaut grossièrement à 200 000 instructions CPU qui auraient pu être exécutées pendant ce temps. Cela équivaut à une estimation conservatrice de 36 transferts ERC-20 qui auraient pu être effectués!

Aggravant ce problème, les blockchains présentent de nombreux schémas d'accès inefficaces pour la lecture et l'écriture de l'état. Par exemple, la structure non séquentielle du trie de Merkle Patricia conduit intrinsèquement à ces opérations d'entrée/sortie (E/S) sur le disque, en lisant et écrivant à divers emplacements imprévisibles sur le disque. La nature aléatoire des entrées de transaction et les modifications ultérieures de l'état qu'elles déclenchent conduisent à un schéma d'accès de données éparpillées qui ralentit considérablement le processus de vérification et de mise à jour de l'état et n'utilise qu'une partie de capacité de l'appareil matériel.

Dans l'ensemble, les primitives de gestion de l'état pour les blockchains sont loin d'atteindre leur potentiel absolu, et de nombreuses avancées peuvent être faites pour améliorer l'efficacité computationnelle.

Bottleneck #2: Calcul inefficace

Les couches d'exécution sont également confrontées au goulot d'étranglement de la computation inefficace, qui se manifeste de différentes manières.

Tout d'abord, de nombreux processus traitent les transactions séquentiellement, sous-utilisant les processeurs multi-cœurs modernes capables de gérer plusieurs opérations simultanément. Cette exécution séquentielle entraîne des temps d'inactivité CPU inévitables entre les transactions, gaspillant des ressources informatiques précieuses.

De plus, l'utilisation de machines virtuelles implique de traduire les opérations de contrat intelligent de haut niveau en bytecode, un code de niveau inférieur et indépendant de la plate-forme, qui est ensuite exécuté instruction par instruction. Ce processus de traduction et d'exécution introduit une surcharge significative, en particulier pour les applications avec des tâches spécifiques à l'application complexes et fréquemment répétées.

Ces inefficacités conduisent à une utilisation sous-optimale des ressources computationnelles et entravent les performances des couches d'exécution.

Solutions: Accès à l'état inefficace

Il existe plusieurs façons distinctes dont les équipes améliorent le taux auquel l'état peut être récupéré et mis à jour à partir du matériel d'un nœud en cours d'exécution, notamment en simplifiant les structures de données complexes et en trouvant des moyens de réduire les opérations coûteuses d'E/S sur disque qui conduisent à l'enflure de l'état.

Statelessness & In-Memory Computing

Certaines couches d'exécution abordent le problème de l'explosion de l'état en l'acceptant simplement à court terme. Elles déplacent le stockage des données d'état des systèmes basés sur des disques plus lents vers une mémoire vive à accès aléatoire (RAM) plus rapide. L'accès aux informations d'état en RAM réduit significativement la surcharge associée aux opérations sur disque, qui sont plus lentes et plus consommatrices de ressources.

Cependant, cette approche remet en question le principe fondamental de la décentralisation. Stocker des quantités de plus en plus importantes de données d'état dans la RAM nécessite un matériel plus avancé et plus coûteux, ce qui pourrait limiter la capacité des individus à participer en tant qu'opérateurs de nœuds. Par conséquent, à mesure que les exigences en matière de matériel augmentent, moins d'entités peuvent se permettre d'exécuter ces nœuds.

Pour équilibrer l'attrait du calcul en mémoire avec la minimisation de la confiance, à la fois les L1 (comme Ethereum) et les L2 suivent une feuille de route de scalabilité qui repose sur le découplage du rôle d'un validateur en nœuds d'exécution centralisés séparés avec de nombreux nœuds de vérification. Dans ce modèle, des producteurs de blocs très performants avec les exigences matérielles pour calculer en mémoire sont responsables de la génération de blocs, et des preuves cryptographiques (preuves de fraude et de validité) sont utilisées par les nœuds de vérification pour responsabiliser les producteurs de blocs.

En conséquence, ces systèmes devraient permettre aux producteurs de blocs de maximiser leur vitesse car on peut s'attendre à ce qu'ils effectuent des calculs en mémoire, éliminant complètement les E/S sur disque pendant l'exécution. Comme la latence de la RAM est généralement inférieure à 100 nanosecondes, la latence de l'accès à l'état est réduite jusqu'à 1000 fois par rapport aux implémentations basées sur le disque.

En parallèle, des preuves de fraude et de validité sont utilisées à la place du consensus décentralisé pour mettre à l'échelle les propriétés de la minimisation de la confiance du système ainsi que son débit. Par conséquent, des nœuds puissants et centralisés de production de blocs sont contrebalancés par des nœuds vérificateurs pouvant fonctionner sur un matériel beaucoup moins coûteux. Ces nœuds effectuent la fonction critique de vérification indépendante des preuves de transitions d'état (ou de transitions d'état invalides) pour maintenir une vue précise de l'état sans la charge de stocker l'intégralité de l'état de la chaîne de blocs.

Pour faciliter ce processus de manière minimisée en termes de confiance, les couches d'exécution doivent mettre en œuvre un degré de apatridie, le plus populaire étant le concept de la « non-appartenance faible ». La non-appartenance faible est réalisée en exigeant que les producteurs de blocs fournissent une attestation cryptographique connue sous le nom de témoinà un nœud de vérification. Ce témoin encapsule toutes les modifications d'état proposées par le nouveau bloc, permettant aux validateurs de vérifier ces modifications sans données historiques supplémentaires.

Bien que ce concept puisse être appliqué en utilisant diverses structures arborescentes, les arbres Verkle sont souvent préférés aux arbres de Merkle pour leur efficacité. Les arbres de Merkle nécessitent l'inclusion de tous les hachages des nœuds frères le long du chemin d'un point de données (feuille) jusqu'à la racine de l'arbre pour prouver l'intégrité des données. Cette exigence signifie que la taille du témoin (la preuve d'intégrité) augmente avec la hauteur de l'arbre, car chaque niveau nécessite des hachages supplémentaires. Par conséquent, vérifier l'intégrité des données dans les arbres de Merkle devient intensif en calcul et coûteux, surtout pour les grands ensembles de données. En revanche, les arbres de Verkle rationalisent ce processus, réduisant les surdépenses associées à la génération et à la vérification de nouveaux blocs.

Verkle tree mise à l'échelle à partir de l'« Arbre Verkle » inévitable d'Ethereum

Les arbres Verkle améliorent la structure des arbres Merkle traditionnels en rationalisant les connexions entre les feuilles et la racine et en éliminant la nécessité d'inclure les nœuds frères dans le processus de vérification. Dans un arbre Verkle, vérifier une preuve ne nécessite que la valeur du nœud feuille, un engagement envers le nœud racine et un seul engagement vectoriel basé sur des engagements polynomiaux, remplaçant les multiples engagements basés sur des hachages que l'on trouve dans les arbres Merkle. Ce changement permet aux arbres Verkle de conserver un témoin de taille fixe, qui ne s'accroît pas avec la hauteur de l'arbre ou le nombre de feuilles vérifiées, améliorant considérablement l'efficacité du stockage et du calcul lors de la vérification des données.

Au cours des prochaines années, nous verrons des mises en œuvre de l'état de non-appartenance se produire aux niveaux L1 et L2 avec des configurations variables. Selon la dernière feuille de route d'Ethereum, les validateurs peuvent compter sur les constructeurs de blocs pour fournir des preuves Verkle concernant l'état de certains blocs et vérifier ces preuves légères au lieu de maintenir directement l'état d'Ethereum.

Au niveau L2, des équipes comme MegaETHappliquent activement le concept de sans état à la conception de rollups optimistes. Dans leur conception, le nœud séquenceur génère un témoin pour chaque bloc contenant les valeurs d'état nécessaires et les hachages intermédiaires tout en émettant un delta d'état représentant les changements d'état. Les nœuds vérificateurs peuvent ensuite réexécuter n'importe quel bloc en récupérant le témoin de la couche DA ou d'un réseau pair à pair sans stocker l'intégralité de l'état. En parallèle, les nœuds complets mettent à jour leur état en appliquant les deltas d'état diffusés à travers le réseau, ce qui leur permet de rester synchronisés sans réexécuter les transactions ou stocker l'intégralité de l'historique de l'état.

Cependant, il convient également de souligner que les avantages de l'absence d'état et la capacité résultante de calculer en mémoire ne constituent pas une solution miracle pour les performances de la couche d'exécution.

TPS en temps réel provenant de l'article "Comprendre les performances de la couche d'exécution Ethereum" de MegaETH

En tant que co-fondateur de MegaETH, Yilong Li, identifie dans ce qui suitprésentation de recherchesur l'exécution Ethereum, il existe d'autres inefficacités liées aux structures de données et aux motifs d'accès onchain qui restent optimisés.

Améliorer les bases de données

Les équipes travaillant sur les couches d'exécution cherchent des moyens d'améliorer la structure de ces bases de données elles-mêmes afin d'éliminer certains des goulots d'étranglement rencontrés par Ethereum et d'autres blockchains compatibles avec l'EVM lorsqu'elles traitent un accès à l'état inefficace, ce qui a un effet domino sur l'efficacité computationnelle.

En fait, les limites des conceptions de base de données existantes trouvées dans l'EVM informées Monad’s* décision d'aller au-delà de l'optimisation purement pour l'efficacité computationnelle afin d'atteindre la parallélisation. Monad a constaté que même après la mise en œuvre d'une exécution parallèle, ils n'ont vu qu'une légère amélioration des performances car les demandes de lecture et d'écriture multithreadées à la base de données se bloquaient mutuellement. Par conséquent, Monad a mis en œuvre une base de données compatible avec l'E/S asynchrone (AIO), ou un accès parallèle, en tant que partie critique de la solution.

Entrées/sorties asynchrones

Les opérations d'E/S, telles que la lecture depuis ou l'écriture sur des périphériques de stockage, créent souvent des goulots d'étranglement, en particulier avec les disques durs mécaniques (HDD). Ces disques nécessitent le déplacement physique d'une tête de lecture/écriture pour accéder aux données, ce qui peut ralentir considérablement le traitement des données.

AIO adresse ce défi en permettant aux programmes d'effectuer des opérations d'E/S de manière concurrente avec d'autres processus. Essentiellement, un programme peut initier une opération d'E/S et continuer sans attendre sa complétion. Il le fait en enregistrant une fonction de rappel ou une promesse que le système d'exploitation ou une bibliothèque d'E/S remplira une fois l'opération d'E/S terminée. Cette approche asynchrone permet au programme principal de continuer à exécuter d'autres tâches, améliorant ainsi l'efficacité globale en ne restant pas bloqué par l'attente de la complétion des tâches d'E/S.

Les E/S asynchrones peuvent être implémentées à la fois avec des disques durs traditionnels et des lecteurs à état solide (SSD), bien que les avantages soient plus marqués avec les SSD. Les disques durs peuvent effectuer des E/S asynchrones, mais leur nature mécanique signifie qu'ils sont intrinsèquement plus lents que les SSD, qui stockent les données dans une mémoire flash et ne possèdent pas de pièces mobiles, ce qui se traduit par des temps d'accès plus rapides.

Par exemple, Monad utilise un backend d'état personnalisé optimisé pour le stockage SSD, qui prend en charge des niveaux élevés de traitement de données parallèle et réduit la latence d'E/S. Cette configuration est plus efficace que les systèmes qui reposent uniquement sur un stockage traditionnel basé sur des disques ou sur ceux utilisant des bases de données en mémoire, qui peuvent encore rencontrer des retards dus à des écritures de données fréquentes et à des lectures depuis des supports de stockage plus lents.

De même, Reth utilise une méthode qui sépare les opérations de base de données du moteur d'exécution principal de l'EVM. Cette configuration permet au bytecode de l'EVM de s'exécuter séquentiellement sur un seul thread pour maintenir la cohérence, tandis que les tâches d'E/S de la base de données sont déchargées vers des processus parallèles. Reth utilise le modèle d'acteur, un schéma d'architecture logicielle, pour gérer efficacement ces processus parallèles, garantissant que les opérations d'E/S n'interrompent pas l'interpréteur de l'EVM.

Fréquence de la Merklisation de l'État

Un autre vecteur d'optimisation est la fréquence de merklisation de l'état. Le modèle actuel d'Ethereum consistant à merkliser l'état après chaque bloc introduit une surcharge significative, nécessitant des écritures fréquentes sur le disque et des lectures continues à partir du disque et des traversées d'arborescence continues. Les arbres de Merkle fonctionnent généralement en regroupant des hachages intermédiaires en ensembles de 16 (appelés un nœud) et en les stockant dans une base de données de type magasin clé-valeur où la clé est le hachage du nœud et la valeur est le nœud lui-même.

Traverser cet arbre pour trouver et mettre à jour les données nécessite un accès aléatoire au disque pour chaque couche de l'arbre à parcourir, et parcourir un arbre de Merkle naïf nécessitera environ huit requêtes de base de données séquentielles par entrée.

L'approche de Solana consistant à mettre à jour l'engagement d'état uniquement à la fin de chaque époque permet l'amortissement des coûts d'écriture sur de nombreuses transactions durant cette période. Si une entrée d'état est modifiée plusieurs fois au sein de la même époque, chaque écriture ne nécessite pas de mise à jour immédiate de la racine de Merkle. Cela réduit la surcharge computationnelle globale associée aux mises à jour d'état pendant l'époque. Par conséquent, le coût associé à la lecture de l'état reste constant, ou O(1), car l'état peut être lu directement sans avoir besoin de parcourir un chemin de Merkle à chaque fois.

Réduire la fréquence de la merklisation dans Ethereum pourrait diminuer les frais généraux liés à la lecture et à l'écriture de l'état, améliorant ainsi les performances. Cependant, les clients légers devraient rejouer les changements de blocs pour suivre l'état entre les époques ou soumettre des transactions onchain pour la vérification de l'état, et un tel changement n'est actuellement pas compatible avec Ethereum.

Structures de données efficaces et spécialisées

De plus, les structures arborescentes superposées au sein des clients Ethereum existants généralement provoquent des schémas d'accès étatiques inefficaces, contribuant davantage à l'encombrement de l'état. Alors que l'état d'Ethereum est structuré comme un MPT, il est ensuite stocké dans les bases de données des clients Ethereum comme LevelDB,PebbleDB(utilisé par go-ethereum), ou MDBX (employé par Erigon) qui stockent des données dans des arbres de Merkle comme un B-ArbreouLSM-Tree.

Dans cette configuration, une structure de données est enracinée dans une autre structure de données d'un type différent, créant une « amplification de lecture » en naviguant dans des structures d'arbre interne au-dessus des clients qui fonctionnent sous un autre système basé sur un arbre de Merkle. L'amplification de lecture peut être comprise comme le résultat des multiples étapes pour accéder ou mettre à jour les informations contenues dans un état, ce qui nécessite de naviguer dans l'arbre externe pour trouver le point d'entrée dans le MPT avant d'exécuter l'opération requise. En conséquence, le nombre d'accès au disque pour une lecture aléatoire est multiplié par un facteur log(n).

Pour résoudre ce problème, Monad exploite nativement une structure de données Patricia trie sur disque et en mémoire. D'un point de vue technique, les tries de Patricia sont souvent supérieurs à d'autres structures d'arbres de Merkle en raison de leur combinaison unique d'efficacité d'espace, de correspondance de préfixe efficace et de traversée minimale des nœuds. La conception du trie fusionne les nœuds avec des enfants uniques et rationalise les recherches, les insertions et les suppressions, réduisant le nombre d'opérations d'E/S disque ou réseau nécessaires. De plus, l'habileté d'un trie de Patricia à gérer la correspondance de préfixes améliore les performances dans les applications nécessitant des recherches rapides de clés partielles.

Un autre goulot d'étranglement spécifique aux structures arborescentes est que l'accès ou la mise à jour des données nécessite de parcourir plusieurs couches, ce qui entraîne de nombreuses lectures séquentielles sur disque.Laboratoires Souverains... propose de remédier à cette inefficacité en préconisant une configuration d'arbre de Merkle binaire. Ce changement crucial vers une structure binaire réduit considérablement le nombre de chemins potentiels lors de la traversée de l'arbre, réduisant directement les calculs de hachage nécessaires pour les mises à jour, les insertions et les preuves cryptographiques.

Configuration de l'arbre de Merkle binaire de "Nearly Optimal State Merklization" de Sovereign Labs

Un exemple supplémentaire dans cette catégorie est l'équipe Reth configurant Reth pour pré-fetcher les nœuds d'arbre intermédiaire depuis le disque pendant l'exécutionen informant le service de racine de l'État des emplacements de stockage et des comptes touchés.

Expiration de l’État

L'expiration de l'état est un mécanisme visant à gérer et réduire la taille de l'état de la blockchain en supprimant les données qui n'ont pas été consultées pendant une période définie. Bien que l'expiration soit souvent regroupée dans la catégorie de la "sans état", il est essentiel de distinguer ces concepts dans le contexte de l'exécution.

La statelessness améliore l'exécution en augmentant la capacité d'un nœud exécutant à calculer en mémoire, mais les améliorations de l'exécution découlent des exigences matérielles plus importantes sur moins de nœuds exécutant des transactions. En revanche, l'expiration de l'état peut être appliquée aux blockchains avec à la fois quelques et nombreux nœuds exécutants.

Il existe quelques méthodes couramment discutées pour mettre en œuvre l'expiration de l'état :

• Expiration par location : Cette méthode consiste à facturer des frais de maintenance, ou "loyer", pour maintenir des comptes actifs dans la base de données de l'État. Si le loyer n'est pas payé, les comptes sont archivés jusqu'à ce qu'un frais soit payé pour les restaurer.
• Expiration par Temps: Ici, les comptes sont considérés comme inactifs s'ils n'ont pas été consultés, c'est-à-dire qu'aucune transaction ou interaction n'a eu lieu, pendant une durée spécifiée.

Les deux méthodes visent à ne conserver que les données utilisées activement dans un état immédiat et accessible, tout en éliminant les données plus anciennes et moins fréquemment consultées vers un état archivé qui n'alourdit pas le système principal.

En maintenant un état plus petit et plus gérable, l'expiration de l'état réduit le "gonflement de l'état" qui peut sérieusement entraver les performances de la blockchain. Une taille d'état plus petite permet aux nœuds de naviguer et de mettre à jour l'état rapidement, se traduisant par une exécution plus rapide car les nœuds passent moins de temps à scanner et plus de temps à traiter.

Exécution du sharding

Le sharding optimise l'utilisation des ressources et les performances en distribuant les tâches et les données sur un nombre limité de nœuds spécialisés (tous les nœuds n'exécutent pas un état global).

Dans une architecture de blockchain sharded, l'état global est divisé en partitions distinctes appelées shards. Chaque shard maintient sa partie de l'état et est responsable du traitement d'un sous-ensemble des transactions du réseau. Les transactions sont assignées à des shards spécifiques en fonction d'une fonction de sharding déterministe, qui prend en compte divers facteurs tels que l'adresse de l'expéditeur, l'adresse du destinataire et le hash des données de la transaction. Cela minimise le besoin de communication entre shards et permet une exécution de transaction plus efficace.

Diagramme de partage de Vitalik dans "Les limites de la scalabilité de la blockchain"

Cela devient évident lors de l'exploration Le protocole NEARconception de sharding, Belladone, qui permet d'atteindre un état sans état pour mettre en échelle le sharding sans compromettre la minimisation de la confiance.

Dans Nightshade, la blockchain est structurée comme une seule chaîne logique, chaque bloc étant composé de plusieurs "morceaux" et un morceau étant alloué par tranche. Ces morceaux contiennent les transactions et les transitions d'état spécifiques à chaque tranche. Inclure des morceaux de toutes les tranches dans un seul bloc permet d'obtenir une vue unifiée de l'état de la blockchain entière et simplifie le processus de communication entre les tranches.

De la même manière que la séparation constructeur-approprié (PBS) sur Ethereum, Nightshade délimite explicitement les rôles des nœuds conservant l'état et des nœuds sans état. Sur NEAR, les validateurs conservant l'état sont affectés à des fragments spécifiques et sont responsables de la collecte des transactions, de leur exécution et de la production de tranches spécifiques au fragment. Ils maintiennent l'état complet de leur fragment assigné et génèrent des témoins d'état pour que les validateurs les utilisent lors du processus de validation.

Pendant ce temps, les validateurs sans état sont attribués de manière aléatoire pour valider des fragments spécifiques sur une base par bloc. Ils n'ont pas besoin de maintenir l'état complet fragmenté et s'appuient sur des témoins d'état fournis par les producteurs de blocs d'autres fragments pour valider les transitions d'état et les transactions au sein d'un fragment. L'attribution aléatoire des validateurs aux fragments contribue à garantir la sécurité et l'intégrité du réseau, car elle rend plus difficile pour les acteurs malveillants de collusion et de contrôle d'un fragment spécifique.

Étant donné que chaque nœud du réseau doit uniquement gérer les données de sa tranche respective plutôt que l'ensemble des données du réseau, la charge de stockage et de calcul sur les nœuds individuels est réduite.

Solutions: Calcul inefficace

Parallélisation de l’exécution

Il est temps d'aborder le problème de front : la parallélisation. La parallélisation de l'exécution des transactions permet de traiter plusieurs transactions en utilisant simultanément plusieurs ressources informatiques. Cela permet d'augmenter le débit car les ressources matérielles sont augmentées pendant les périodes de forte demande.

Cependant, il est important de considérer que plusieurs composants d'exécution peuvent être parallélisés, dont beaucoup sont mis en œuvre par des coprocesseurs tels que Lagrange* et des clients blockchain alternatifs tels que Firedancerpour améliorer significativement les performances des blockchains. Plus précisément, la parallélisation peut impliquer:

• Accès parallèle à l'état
• Parallélisation des opérations spécifiques
• Paralléliser le consensus et l'exécution

Accès parallèle à l'état

Accès parallèle à l'étatapporte deux avantages critiques:

• Les EVM parallèles répartissent le traitement des transactions sur plusieurs cœurs de CPU. Cette configuration permet de gérer plusieurs transactions simultanément au lieu de les forcer à faire la queue pour une seule ressource.
• Lorsqu'une transaction attend des données provenant du stockage, ce qui peut introduire une latence significative, le système ne reste pas inactif. Au lieu de cela, il peut passer à une autre transaction prête à s'exécuter. Cela est possible car plusieurs cœurs peuvent gérer des tâches différentes de manière indépendante et simultanée.

Le défi principal de la parallélisation de l'exécution des transactions découle de la gestion de l'accès concurrentiel à l'état global partagé sans violer le ACIDrègles de mise à jour des systèmes distribués. Si une blockchain a un tas de transactions s'exécutant en parallèle, certaines d'entre elles entreront en conflit. En conséquence, les deux méthodologies principales pour paralléliser l'accès à l'état diffèrent sur le moment où elles consacrent des ressources à la résolution des conflits: le modèle d'exécution pessimiste (ou verrouillage mémoire) et le modèle d'exécution optimiste.

Exécution pessimiste

Le modèle d'exécution pessimiste est une approche de traitement des transactions exigeant que les transactions déclarent les variables d'état auxquelles elles accéderont (lecture ou écriture) pendant l'exécution. Ces informations sont incluses dans les métadonnées de la transaction, permettant au runtime d'analyser les motifs d'accès avant l'exécution.

En examinant les schémas d'accès en lecture-écriture, le temps d'exécution peut identifier les transactions avec des ensembles d'accès non superposés, permettant une exécution parallèle des transactions non superposées et en lecture seule et améliorant le débit. Le temps d'exécution crée des files d'attente de transactions parallèles pour chaque fil CPU sur un nœud validateur, en veillant à ce que les transactions avec des schémas d'accès non conflictuels soient traitées simultanément.

En raison de ce choix de conception, le modèle d'exécution pessimiste bénéficie d'un contrôle fin sur l'allocation des ressources, permettant de segmenter ou de partitionner l'espace d'état d'une blockchain.

La parallélisation crée efficacement plusieurs fragments d'exécution indépendants et synchronement composables, étayés par un modèle de sécurité unifié. Elle permet de résoudre la congestion du réseau et d'optimiser les coûts de gaz grâce à une gestion précise des ressources et des marchés de frais dynamiques. En identifiant les "points chauds" d'accès à l'état (zones de forte demande transactionnelle), le système peut mettre en œuvre des optimisations ciblées telles que la tarification différenciée des frais, la limitation du débit ou l'allocation de ressources supplémentaires aux états à forte contention. Il est important de noter que l'implémentation actuelle de la parallélisation par Solana ne réaliser pleinement le potentiel des marchés de frais localisés.

Pour garantir la cohérence des données lors d'un accès concurrent, le modèle d'exécution pessimiste utilise un mécanisme de verrouillage. Avant qu'une transaction puisse accéder à une variable d'état spécifique, elle doit acquérir un verrou sur cette variable. Le verrou offre à la transaction un accès exclusif à la variable, empêchant d'autres transactions de la modifier simultanément. Le verrou est libéré une fois la transaction exécutée, permettant à d'autres transactions d'accéder à la variable.

Dans le Niveau de la merruntime, qui implémente ce modèle d'exécution pessimiste, les transactions spécifient les comptes qu'elles liront ou écriront pendant l'exécution. Sealevel analyse les schémas d'accès et construit des files d'attente de transactions parallèles pour chaque thread CPU sur un nœud validateur. Si un compte est accédé plusieurs fois, il est répertorié séquentiellement dans une file unique pour éviter les conflits. Les transactions non traitées dans le temps de bloc du nœud leader sont regroupées et transmises au prochain leader programmé pour traitement.

Les systèmes basés sur les sorties de transaction non dépensées (UTXO) améliorent également l'efficacité computationnelle. Les UTXO impliquent des unités spécifiques de monnaie, les UTXO, associées au portefeuille d'un individu. Pour chacune des transactions dudit portefeuille, les UTXO sont dépensés et remplacés par de nouveaux ; un ou plusieurs UTXO sont créés pour le destinataire, représentant le paiement, et un autre est généralement créé pour l'initiateur, représentant tout changement dû en retour.

En définissant quels contrats seront touchés, les transactions qui touchent des ensembles de contrats disjoint peuvent être exécutées en parallèle en exécutant des nœuds (ce qui peut être réalisé dans le modèle de données "comptes" avec des listes d'accès strictes). Cependant, pour gagner en compatibilité avec les contrats intelligents de style Ethereum, les schémas UTXO tels que la contrainte de bloc de Fuel obligent les nœuds produisant des blocs à exécuter séquentiellement des transactions avec des listes d'accès qui se chevauchent.

Néanmoins, le modèle d’exécution pessimiste a des limites. Les transactions doivent déclarer avec précision leurs modèles d’accès dès le départ, ce qui peut être difficile pour les transactions complexes ou dynamiques où les modèles d’accès peuvent dépendre de données d’entrée ou d’une logique conditionnelle. Des déclarations de modèle d’accès inexactes ou incomplètes peuvent entraîner des performances sous-optimales et des erreurs d’exécution potentielles. De plus, le mécanisme de verrouillage peut introduire une latence et réduire la concurrence lorsque de nombreuses transactions sont en concurrence pour les mêmes variables d’état. Cette contention peut créer des goulots d’étranglement en termes de performances, car les transactions peuvent passer une partie importante de leur temps d’exécution à attendre d’acquérir des verrous sur des variables d’état à forte demande.

Plus important encore, ce modèle place un fardeau considérable sur les développeurs, qui doivent avoir une compréhension approfondie des dépendances de données de leurs contrats pour spécifier avec précision les accès à l'état nécessaire à l'avance. Cette complexité peut introduire des défis, en particulier dans la conception d'applications avec des interactions d'état dynamiques et complexes, telles que les échanges décentralisés ou les fournisseurs de liquidité automatisés.

Exécution optimiste

En revanche, le modèle d'exécution optimiste adopte une approche “speculative” à l'exécution des transactions, permettant aux transactions de s'exécuter en parallèle sans avoir besoin de déclarations d'accès à l'état préalable.

Au lieu de prévenir les conflits avant qu'ils ne se produisent, les transactions sont exécutées de manière optimiste en parallèle, en supposant qu'elles sont indépendantes. Le temps d'exécution utilise des techniques comme contrôle de la concurrence multi-version(MVCC) etmémoire transactionnelle logicielle(STM) pour suivre les ensembles de lectures et d'écritures pendant l'exécution. Après l'exécution, le temps d'exécution détecte les conflits ou les dépendances. Il prend des mesures correctives, telles que l'abandon et la ré-exécution des transactions en conflit, mais peut le faire en lisant depuis la mémoire au lieu du disque pour identifier les transactions en conflit.

Le modèle d'exécution optimiste simplifie le processus de développement, permettant aux programmeurs de se concentrer sur l'écriture de la logique du contrat sans se soucier de déclarer des schémas d'accès à l'état. Parce que les transactions n'ont pas besoin de déclarer leurs interactions avec l'état à l'avance, les développeurs bénéficient de plus de liberté dans la conception de leurs contrats intelligents, permettant des interactions plus complexes et dynamiques avec l'état de la blockchain. Le modèle d'exécution optimiste est particulièrement bien adapté aux plateformes qui prennent en charge un volume élevé de transactions et des dapps complexes, car il peut offrir une plus grande capacité de traitement et une plus grande évolutivité que le modèle pessimiste.

Une mise en œuvre notable de ce modèle se trouve dans Aptoset le MoveVM deLaboratoires de Mouvement*, qui utilise une technique connue sous le nom de Block-STM. Dans Block-STM, les transactions sont d'abord exécutées en parallèle; ensuite, les transactions conflictuelles sont identifiées et programmées pour une nouvelle exécution en fonction des dépendances détectées. Cette approche garantit que les ressources de traitement sont continuellement utilisées, améliorant le débit tout en maintenant l'intégrité du flux de transactions.

Le bloc-STM d'Aptos de « Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing »

Malgré ses avantages, le modèle d'exécution optimiste comporte également des défis. La nécessité de détecter les conflits à l'exécution et la possibilité d'annulations et de tentatives de nouveau introduisent une surcharge computationnelle et de la complexité. De plus, la maintenance de plusieurs versions de l'état et la gestion de la surcharge associée à la résolution des conflits nécessitent une conception système sophistiquée et des mécanismes de contrôle de la concurrence robustes pour garantir l'intégrité et les performances de la blockchain.

Block-STM exploite MVCC pour gérer efficacement les écritures concurrentes et maintenir plusieurs versions de données, empêchant ainsi les conflits entre les opérations d'écriture simultanées. Il intègre un planificateur collaboratif pour coordonner l'exécution et la validation des tâches à travers plusieurs threads, garantissant que les transactions sont validées dans l'ordre où elles ont été lancées. Cette configuration réduit au minimum les annulations de transactions en utilisant une estimation dynamique des dépendances, ce qui permet aux transactions avec des dépendances d'attendre efficacement et de résoudre ces dépendances avant de continuer.

De plus, le modèle de compte utilisé par MoveVM diffère de celui de l'EVM d'Ethereum, ce qui entraîne moins de collisions. Dans Ethereum, un jeton est généralement géré par un seul contrat intelligent, ce qui peut entraîner l'interaction de plusieurs transactions de jetons via la même adresse de contrat, augmentant ainsi la probabilité de conflits. En revanche, MoveVM attribue des jetons à des comptes d'utilisateurs individuels, réduisant ainsi le risque de tels conflits car chaque transaction interagit généralement avec des adresses de compte différentes.

Dans Monad, l'ensemble initial de transactions exécutées en parallèle peut être encadré comme une phase E/S, qui peut produire des résultats immédiatement commettables, et la phase de "reprise" suivante, qui nécessite un petit travail pour effacer les transactions restantes en conflit. Ces transitions conflictuelles sont mises en cache et extraites, ce qui permet de réduire les coûts d'exécution car elles résident en mémoire. Alors que la plupart des états résident sur le disque, les transactions en conflit sont rapidement accessibles au moment de l'exécution.

Les modèles d'exécution pessimistes et optimistes offrent des approches distinctes pour gérer l'exécution des transactions et la gestion de l'état dans les blockchains. Le choix entre ces modèles implique des compromis entre la complexité initiale de la spécification de l'accès à l'état et les surcharges computationnelles associées à la résolution dynamique des conflits.

Parallélisme des données et des tâches

Le parallélisme des données et des tâches vise à optimiser les performances en répartissant les charges de calcul sur plusieurs processeurs : le parallélisme des données segmente un ensemble de données pour un traitement simultané, tandis que le parallélisme des tâches attribue différentes tâches à divers processeurs pour fonctionner simultanément.

Ces optimisations sont distinctes mais interdépendantes avec le parallélisme d'accès à l'état, qui gère et synchronise l'accès aux ressources partagées comme la mémoire ou les bases de données pour éviter les conflits et garantir l'intégrité des données lorsque plusieurs processus ou threads fonctionnent simultanément.

Parallélisme des données

Le parallélisme des données implique de paralléliser des opérations spécifiques sur plusieurs éléments de données simultanément. Cette approche est particulièrement bénéfique lorsque la même opération doit être appliquée à un grand ensemble de données ou lorsque des opérations intensives en calcul doivent être effectuées sur plusieurs valeurs d'entrée. Le déverrouillage clé provient de la distribution des données sur plusieurs unités de traitement et de l'exécution simultanée de la même opération sur différents éléments de données.

Une technique courante pour le parallélisme des données est instruction unique, données multiples(SIMD), qui permet l'exécution simultanée d'une seule instruction sur plusieurs éléments de données. Les processeurs modernes ont souvent des capacités SIMD intégrées, ce qui leur permet d'effectuer des opérations parallèles sur plusieurs points de données. En utilisant les instructions SIMD, les développeurs peuvent obtenir des accélérations significatives pour certains types d'opérations, telles que les calculs mathématiques, les transformations de données ou le traitement de signaux.

Par exemple, considérez un scénario où vous devez appliquer une fonction mathématique complexe à un grand tableau de nombres. Au lieu de traiter chaque nombre séquentiellement, SIMD peut opérer sur plusieurs nombres simultanément. Ce traitement simultané est réalisé en chargeant un sous-ensemble des nombres dans les registres SIMD du CPU, en exécutant la fonction mathématique sur tous les nombres chargés en parallèle, puis en stockant les résultats dans la mémoire. En traitant plusieurs nombres à la fois, SIMD peut grandement réduire le temps d'exécution global.

Travail de Firedancer sur ED25519la vérification de signature démontre la puissance de SIMD pour optimiser les calculs complexes. Le processus de vérification de signature implique des opérations arithmétiques dans les champs de Galois, ce qui peut être intensif en termes de calcul. En utilisant les instructions SIMD, Firedancer peut effectuer ces opérations sur plusieurs éléments de données simultanément, ce qui se traduit par des améliorations de performance significatives. Ces optimisations seront cruciales pour améliorer les performances de Solana, qui a déjà mis en œuvre la parallélisation de l'accès à l'état.

Parallélisme des tâches

La parallélisme des tâches implique de paralléliser différentes tâches ou opérations au sein d'un programme sur plusieurs unités de traitement. Cette approche est utile lorsque un programme est composé de plusieurs tâches indépendantes qui peuvent être exécutées simultanément. En attribuant chaque tâche à une unité de traitement distincte, comme un cœur de CPU ou un GPU, le temps d'exécution global peut être réduit.

La parallélisme des tâches est couramment utilisée dans des scénarios où un programme doit effectuer simultanément de multiples opérations complexes. Par exemple, considérez une application de traitement vidéo qui doit appliquer différents filtres et effets à un flux vidéo en temps réel. Au lieu d'utiliser chaque unité de calcul pour appliquer collectivement chaque filtre séquentiellement, la parallélisme des tâches peut répartir la charge de travail sur les multiples unités de traitement. Une unité de traitement peut être responsable d'appliquer un filtre de flou tandis qu'une autre unité applique un filtre de correction des couleurs, et ainsi de suite. En exécutant ces tâches en parallèle, l'application peut obtenir un traitement plus rapide et maintenir une expérience utilisateur fluide.

Lagrange’s @lagrangelabsA primer on big data introducing ZK MapReduce (ZKMR) exploits data and task parallelism to efficiently parallelize and generate proofs of distributed computations on large datasets. In the map phase, the input dataset is partitioned into smaller chunks, and each chunk is processed independently by a separate mapper worker or machine in parallel (task parallelism). The “map” operation can be parallelized within each mapper task across multiple cores or processors (data parallelism). Similarly, in the reduce phase, the “reduce” operation on the values associated with each key can be parallelized within each reducer task (data parallelism). In contrast, the reducer tasks are executed parallel across multiple workers (task parallelism).

En combinant le parallélisme des données et le parallélisme des tâches, ZKMR peut atteindre une mise à l'échelle et des performances efficaces pour des calculs complexes sur des ensembles de données massifs tout en maintenant des garanties de zéro connaissance grâce à la composition de preuves récursive.

Vérification d'une procédure MapReduce arbitraire dans ZK à partir de "Introducing ZK MapReduce" de Lagrange

La capacité de Lagrange à générer des preuves de stockage pour les calculs SQL sur @lagrangelabs/Annonce-de-Testnet-Euclid-la-première-base-de-données-vérifiable-d-Ethereum-et-le-coprocesseur-ZK-cc4a5595365c">888 888 emplacements de stockage en 1 minute et 20 secondes démontrent la puissance de ZKMR, ainsi que la parallélisme des tâches et des données qui le sous-tendent. De plus, les récents de Lagrange Arbres ReckleLe document souligne la nécessité du parallélisme en ce qu'il garantit que les preuves par lot des données onchain sont également calculables en 𝑂(log𝑛), indépendamment de la taille du lot.

Parallélisation du consensus & de l'exécution

Bien que cet article ne traite pas du consensus, les blockchains peuvent également paralléliser le processus de consensus et d'exécution. Les blockchains traditionnelles traitent souvent les transactions séquentiellement, atteignant un consensus sur les transactions d'un bloc (bloc N) avant de les exécuter. Le traitement parallèle des phases de consensus et d'exécution augmente considérablement l'efficacité de l'exécution et est une technique exemplifiée par des systèmes tels que Monad. Alors que le réseau atteint un consensus pour le bloc N, il exécute simultanément les transactions pour le bloc précédent (N-1).

Cette stratégie garantit une utilisation continue et efficace des ressources informatiques, réduisant efficacement les temps d'inactivité et améliorant la capacité du réseau à traiter rapidement les transactions. Ces améliorations augmentent le débit du système et le coût en capital nécessaire pour spammer le réseau.

Interprètes & Réduction des frais généraux

Lorsque des contrats intelligents sont rédigés dans des langages comme Solidity, ils sont d'abord compilés en bytecode de niveau inférieur. Ensuite, l'EVM utilise un interprète pour exécuter ce bytecode. L'interprète lit et exécute chaque instruction séquentiellement, semblable à la traduction en temps réel d'une langue étrangère pendant qu'elle est parlée. Paradigm’s dernier article sur Rethindique que cela entraîne des frais généraux car chaque instruction doit être traitée individuellement et convertie du bytecode en instructions machine pendant l'exécution.

Reth adresse les inefficacités de l'EVM en incorporant un compilateur juste-à-temps (JIT). Ce compilateur traduit le bytecode en code machine natif juste avant l'exécution, contournant le processus d'interprétation intensif en ressources généralement requis pendant l'exécution.

La Article Rethmentionne que 50% du temps d'exécution de l'EVM sous un système basé sur un interprète est dédié à des processus que le JIT pourrait théoriquement optimiser, suggérant la possibilité de doubler la vitesse d'exécution avec la mise en œuvre du JIT. Cependant, comme le souligne Yilong dans cette présentation, alors que le JIT peut réduire de manière significative le temps nécessaire pour traiter des opcodes spécifiques, cela peut ne pas avoir un impact drastique sur l'exécution globale. Cela est dû au fait qu'une partie substantielle des 50% du temps d'exécution de l'EVM pris par le JIT concerneopérations "hôte" et "système"(Diapositive 13), qui ne sont pas propices aux optimisations JIT comme "arithmétique" ou "contrôle" en raison de leur nature non computationnelle.

Bien que les interpréteurs puissent limiter les performances, ils créent la possibilité de « traduction », ce qui augmente la portée du code qui peut tirer parti de nouvelles machines virtuelles, réduisant ainsi la surcharge pour les développeurs d’utiliser l’espace de blocs du concepteur. Par exemple, Movement Labs a développé Fractal, permettant aux développeurs de déployer leurs contrats basés sur Solidity sur MoveVM. Fractal fonctionne en compilant Solidity dans un langage intermédiaire contenant des instructions articulées dans des opcodes EVM, qui sont ensuite mappées à leurs homologues de bytecode MoveVM, ce qui permet aux contrats Solidity de s’exécuter dans l’environnement MoveVM.

Machines d'États Spécialisées et Personnalisées

Personnaliser la couche d'exécution implique la conception de machines à états spécialisées optimisées pour des applications spécifiques. Cela signifie non seulement qu'un environnement d'exécution peut se passer entièrement d'une machine virtuelle, mais cela permet également aux applications de personnaliser le jeu d'instructions (ISA), des structures de données et un modèle d'exécution à leurs besoins spécifiques. Le principal avantage en termes de performances de personnaliser une ISA pour une application spécifique réside dans la réduction des coûts de traduction des schémas computationnels de l'application en instructions générales d'une ISA traditionnelle. Les CPU à usage général utilisent des ensembles d'instructions de base (c'est-à-dire, add, load, branch) pour prendre en charge l'exécution de différents types de logiciels. Cependant, lorsque les applications répètent fréquemment les mêmes opérations complexes, mettre en œuvre ces schémas à l'aide de séquences d'instructions simples devient inefficace.

Par exemple, les applications de base de données peuvent avoir besoin de parcourir constamment des structures de données arborescentes, de rechercher des entrées, de mettre à jour des valeurs et de rééquilibrer des arborescences. Sur un processeur normal, le mappage de ces opérations de haut niveau nécessite de les diviser en longues séquences de micro-opérations de bas niveau, telles que les charges, les magasins, les branches et l’arithmétique, s’exécutant individuellement sur le matériel général. En revanche, un ISA personnalisé pour les bases de données peut fusionner ces modèles récurrents en instructions plus larges optimisées qui exploitent du matériel spécialisé. Une instruction « TraverseTree » pourrait calculer les adresses mémoire, charger les nœuds pertinents et comparer les clés à l’aide de circuits de comparaison parallèles conçus pour cette opération. « UpdateEntry » peut directement collecter l’entrée à partir de la disposition de stockage de base de données optimisée, la modifier et valider le nouvel état, le tout dans une seule instruction.

Cela élimine les frais généraux redondants liés à la traduction des opérations de haut niveau en instructions simples. Cela permet également au matériel d'exécuter de manière optimale l'application en utilisant moins mais plus larges, des instructions explicitement parallèles adaptées précisément à ses besoins.

LayerN’s Nord démontre les avantages en termes de performances des environnements d’exécution et des structures de données spécialisés grâce à leur cas d’utilisation spécifique d’un carnet d’ordres vérifiable. L’approche de LayerN se concentre sur l’optimisation du placement des transactions dans la structure de données du carnet d’ordres, tandis que leur mécanisme de pipelining est conçu pour insérer efficacement les nouveaux ordres dans la position appropriée dans l’arborescence de données du carnet d’ordres. En adaptant la structure de données et l’algorithme d’insertion aux exigences spécifiques d’un carnet d’ordres, LayerN permet d’obtenir un placement d’ordres à faible latence et un débit élevé.

Alternativement, il est possible de se tourner vers des environnements d'exécution polyvalents qui permettent des modules arbitrairement programmables que les applications peuvent intégrer pour optimiser leurs performances. Cette approche privilégie l'expérience des développeurs par rapport aux performances brutes.

FluentetCWDutiliser une stratégie qui équilibre les compromis entre l'optimisation des performances informatiques brutes et l'amélioration de l'expérience des développeurs et la compatibilité de l'écosystème. Cette approche repose sur l'utilisation de WebAssembly (Wasm) comme machine virtuelle pour exécuter du code. Wasm est devenu un choix privilégié dans le développement web en raison de son large support linguistique et du degré élevé auquel il a été adopté.

La décision d'un développeur d'utiliser Wasm plutôt que l'exécution native du client reflète une préférence stratégique pour la polyvalence et la large accessibilité d'un environnement d'exécution général. Bien que l'exécution native, qui exécute le code directement sur le matériel sans machine virtuelle, puisse offrir de meilleures performances, elle limite la compatibilité multiplateforme et est moins accessible aux développeurs. En revanche, Wasm garantit un environnement d'exécution uniforme et sécurisé sur différentes plates-formes, bien qu'il n'atteigne pas la même vitesse brute que l'exécution native. Ce compromis est conforme aux philosophies de conception de Fluent et de CWD, en privilégiant la productivité des développeurs et l'intégration plus large de l'écosystème par rapport à l'efficacité maximale des performances.

Déploiement CosmWasm (CWD), en particulier, illustre cette approche non seulement en utilisant Wasm pour l'exécution de contrats intelligents, mais aussi en l'incorporant dans un cadre plus vaste conçu pour soutenir les subtilités des opérations de la blockchain. Enrichi avec une « logique périphérique », ce cadre offre une gestion avancée des comptes, un mécanisme de gaz personnalisable et un ordonnancement optimisé des transactions. Ces fonctionnalités contribuent à un environnement de développement flexible, efficace et sécurisé qui permet aux développeurs de créer relativement facilement des dapps évolutifs et complexes.

Stackr* adopte une approche différente en combinant les avantages des environnements d'exécution personnalisés avec la flexibilité des plateformes de contrats intelligents traditionnelles. Stackr permet aux développeurs de coder des applications en tant que rollups, ce qui leur permet de définir leurs propres règles pour l'ordonnancement, l'exécution et la configuration des transactions. Dans le modèle Stackr, les développeurs peuvent choisir l'ISA, les structures de données et le modèle d'exécution qui conviennent le mieux aux besoins de leur application.

La conception de micro-rollup de Stackr de "Présentation du SDK Stackr"

Avec Stackr, les développeurs peuvent appliquer des règles de transition d'état directement dans le temps d'exécution de l'application plutôt que d'être contraints par les règles d'une machine virtuelle à usage général, leur donnant la possibilité de rationaliser leur ensemble d'instructions pour être plus efficace et redéfinir l'ensemble des choses qui peuvent être faites dans un environnement d'exécution.

Cela se traduit par une exécution plus légère et plus efficace, car la logique métier est implémentée au niveau du client, éliminant ainsi le besoin de coûteuses invocations et validations de contrats intelligents. En conséquence, les possibilités d'extension de la configuration d'une application se multiplient en termes de différents types de langages, structures de données et signatures que les développeurs peuvent utiliser pour une seule application sans sacrifier les performances.

Conclusion

Il existe plusieurs chemins vers des performances optimales de la couche d'exécution.

Aucune optimisation singulière de l'accès à l'état ou de la parallélisation ne se démarque en tant que point de différenciation technique propriétaire entre les couches d'exécution lors de la tentative de capture de dapps. Comme nous l'avons vu, les avantages de la parallélisation basée sur les ressources sur Solana peuvent être également appliqués au modèle UTXO de Fuel. Tout le monde peut utiliser Amazon’ssolutions perspicaces pour améliorer la scalabilité horizontale grâce au shardinget améliorer les performances de la couche d'exécution.

Alors que la performance de la couche d'exécution est un vecteur critique pour séduire les constructeurs d'applications décentralisées, les nouveaux L1 et L2 centrés sur l'amélioration de l'exécution doivent rivaliser sur d'autres variables, notamment la sécurité, l'interopérabilité et la compatibilité avec les outils existants. Pour cette raison, la multiplication de nouvelles couches d'interopérabilité - de Nebra à Statenet en passant par AggLayer de Polygon - sera cruciale pour les développeurs qui achètent de l'espace de blocs de designer, car ils peuvent construire ou acheter de l'espace de bloc spécialisé sans sacrifier la composabilité synchrone et la liquidité partagée des L1 généralistes traditionnels.

Les améliorations de la gestion de l'état et de l'efficacité computationnelle sont interdépendantes.

À travers les communautés concevant de nouvelles couches d'exécution, la parallélisation de l'accès à l'état est devenue un mème déterminant pour les améliorations de performance qu'ils promettent d'apporter. Même si cela est pour une bonne raison, car cela pourrait mener à un Une amélioration de 5x dans l'exécution de l'EVM, les preuves des premières expérimentations de Monad avec la parallélisation démontrent que son rôle est surévalué si d'autres améliorations, telles que l'I/O asynchrone, ne sont pas développées en parallèle.

Sur cette base, nous pouvons conclure que l'efficacité computationnelle n'est souvent atteinte que lorsque nous améliorons l'accès et le stockage de l'état. Une gestion efficace de l'état réduit le temps et les ressources nécessaires pour accéder et manipuler les données, ce qui accélère le traitement et réduit la charge computationnelle.

Poussant encore plus loin, les incumbents peuvent faire des choix dépendant du chemin qui entravent leur capacité à rivaliser avec les nouveaux designs de blockchain qui réarchitectent la façon dont l'état est géré et mis à jour, compte tenu de l'inertie qu'implique un hard fork. En conséquence, des couches d'exécution spécialisées et modulaires ainsi que des L1 alternatifs peuvent être en mesure de créer une défensibilité autour des choix de conception pour un stockage d'état plus efficace et des protocoles pour le lire et y écrire. Ces décisions de conception offrent un avantage concurrentiel, car les incumbents peuvent rencontrer de l'inertie dans la mise à jour de leurs structures de base de données sans un hard fork.

En fin de compte, les valeurs de l'espace de blocs impactent l'espace de conception des couches d'exécution.

En comprenant comment nous pouvons améliorer les couches d'exécution, nous pouvons maintenant délimiter que les classes d'optimisations diffèrent selon deux choix de conception critiques : qui exécute les transactions et combien de nœuds doivent être impliqués ? Les techniques disponibles pour les développeurs pour résoudre les goulots d'étranglement d'exécution diffèrent considérablement en fonction des réponses initiales d'une équipe à ces questions.

D'une part, des L1 monolithiques comme Solana et Monad refusent de séparer le rôle du validateur en nœuds puissants et faibles hétérogènes pour accélérer les performances. « Accepter » l'engorgement de l'état à court terme n'est pas une solution viable, ils misent donc sur des améliorations au niveau de la base de données et d'autres composants du moteur de production de blocs, tels que le consensus, pour compenser le plus grand nombre de nœuds d'exécution considérés comme un composant critique et une valeur fondamentale du réseau. Étant donné que les modèles de sécurité de ces L1 reposent sur le consensus d'un ensemble plus distribué de validateurs avec des exigences matérielles moins strictes, leurs données doivent être écrites dans une base de données stockée sur un disque, ce qui est nécessairement moins cher pour une blockchain sans permission et maximisant la décentralisation.

D'autre part, des projets comme Ethereum et ses L2s suivent une feuille de route qui penche vers la centralisation à travers leurs nœuds d'exécution, grâce à des constructeurs de blocs centralisés tenus pour responsables par des nœuds proposants vérificateurs plus faibles, via des preuves de fraude ou de validité.

Supposons que les “exécuteurs” centralisés de transactions et de transitions d'état soient considérés comme acceptables dans la poursuite d'un avenir décentralisé. Dans ce cas, la loi de la physique stipule que les systèmes qui peuvent 1) ajouter des blocs à une chaîne sans nécessiter que plusieurs acteurs ré-exécutent les transactions, 2) augmenter les exigences des validateurs pour maximiser le calcul en mémoire (et ignorer le problème d'encombrement de l'état), et 3) réduire la latence et les goulots d'étranglement du consensus l'emportent clairement par rapport aux systèmes reposant sur une décentralisation et un consensus étendus parmi les nœuds.

En cherchant un équilibre entre la scalabilité et la minimisation de la confiance, il devient évident que l'objectif des couches d'exécution ne doit pas être d'optimiser aveuglément la décentralisation, ni l'exécution doit toujours être complètement sans permission.

Alors que nous développons et mettons en œuvre un éventail plus large d'outils cryptographiques, tels que la validité et les preuves de fraude, nous réduisons efficacement le nombre de nœuds nécessaires pour résister à la censure et maintenir la sécurité et la vivacité. Cependant, cette approche implique des compromis, impactant potentiellement la résistance à la censure, l'intégrité de l'ordonnancement et les garanties de vivacité en raison de la centralisation possible des exécuteurs.

Comme l’a noté Sreeram, la « décentralisation minimale viable » ne signifie pas que « la validation doit être sans permission », mais qu’elle doit « simplement être encouragée à juste titre ». Cela signifie qu’un système bien surveillé, où les validateurs font face à des répercussions importantes en cas d’inconduite, peut maintenir la sécurité et la vivacité sans avoir besoin d’une décentralisation excessive (h/t Sreeram).

De tels modèles de gouvernance sont déjà en cours de test dans des applications pratiques. Par exemple, des rollups comme Arbitrum explorent des systèmes de gouvernance ou de comités pour faire respecter les règles d'ordonnancement des transactions et la sélection des leaders, et ils envisagent des mécanismes où les séquenceurs utilisent des données onchain pour faire respecter les politiques d'ordonnancement des transactions.

Malgré ces avancées, il n'existe pas de « frontière optimale de Pareto » définitive pour équilibrer la décentralisation avec les performances.

Les considérations idéologiques et techniques continuent de favoriser la décentralisation des nœuds d'exécution pour valider l'état. Bien que la centralisation des nœuds réduise les surcharges de consensus et que la mise à niveau du matériel puisse considérablement améliorer les performances, il reste à voir si ces optimisations attireront les développeurs axés sur la création d'applications résistantes à la censure et dans quelle mesure la résistance à la censure reste une valeur fondamentale dans l'industrie.

*désigne une société du portefeuille Archetype

Avertissement：

1. Cet article est repris de [miroir )], Transmettre le titre original 'Designer Blockspace: The Future of Execution Environments', Tous les droits d'auteur appartiennent à l'auteur original [GateBenjamin Funk]. If there are objections to this reprint, please contact the Gate Learné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 pas des conseils en investissement.

3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.