Quelle est l’importance de la parallélisation d’EVM ? Ou est-ce la fin du jeu sous l’hégémonie de l’EVM ?

TL;DR

• Le concept Parallel EVM est misé sur plusieurs VC de premier plan : Paradigm, Jump, Dragonfly, etc.
• Le projet représentatif est Monad, et il existe également Sei, MegaETH, Polygon, Neon EVM, BSC, etc. Certains sont en L1, d’autres en L2. Il n’existe pas d’informations publiques complètes sur les différences spécifiques entre les équipes.
• Bien que Parallel EVM signifie littéralement « parallélisation », il s’agit en fait d’une optimisation spéciale des performances de chaque composant d’EVM, ses efforts sont donc susceptibles de représenter la limite de performances selon la norme EVM.
• Difficulté : en plus de reconstruire l’ensemble de la pile technologique, il s’agit également de savoir à l’avance si des transactions parallèles entreront en conflit et d’évaluer l’efficacité de la réexécution après avoir rencontré des conflits.
• Défi : Comment construire la différenciation dans l’écosystème open source et comment trouver un équilibre entre décentralisation et performance.

Après que l’algorithme de consensus, la DA (couche de données) et la technologie à preuve de connaissance nulle aient été largement étudiés et itérés, la prochaine technologie de base à attirer l’attention est Parallel EVM. Le marché des capitaux a également investi des centaines de millions de dollars dans ce domaine. narratif, et de nombreuses technologies uniques sont nées.Une startup de niveau bête.

La communauté a commencé à s’intéresser à Parallel EVM (parallélisation EVM), qui provient du même mot-clé mentionné par Georgios Konstantopoulos (CTO de Paradigm) et Haseeb Qureshi de Dragonfly lorsqu’ils envisageaient les tendances 2024 fin 2023. Cependant, il n’y a pas beaucoup de détails sur ce sujet, et beaucoup de gens pensent qu’il ne s’agit pas d’un concept nouveau. EVM et calcul parallèle sont respectivement des concepts relativement matures. Pourquoi est-ce une tendance importante de combiner ces deux mots ? Tissu de laine ?

Mais il s’agit encore d’un sujet très spécialisé, à tel point que si l’on regarde les résumés annuels et les prévisions de tendances de nombreux instituts de recherche, Parallel EVM n’est pas mentionné. Il s’agit donc d’un concept encore nouveau qui n’a pas encore fait l’objet d’un consensus à grande échelle. De plus, ce concept est similaire à des sujets tels que l’algorithme de consensus et l’AD. Ils sont tous purement liés à la technologie, donc encore moins de personnes y prêtent attention.

L’avantage le plus direct de Paralle EVM est de permettre aux applications décentralisées existantes d’atteindre des performances au niveau Internet. On peut même dire que Parallel EVM est la seule nouvelle technologie capable non seulement d’utiliser (un grand nombre de contrats intelligents matures) existants, mais également d’atteindre un débit de chaîne publique parallélisé et performant.

Paradigm attend avec impatience d’entrer dans le jeu depuis longtemps et Jump parie gros.

Selon Fortune, Paradigm prévoit de diriger le dernier cycle d’investissement de Monad, en levant 200 millions de dollars pour une valorisation de 3 milliards de dollars. Bien qu’il s’agisse du premier concept d’équipe Parallel EVM dans lequel Paradigm envisage d’investir, ils s’intéressent en fait à cette technologie depuis de nombreuses années. Georgios Konstantopoulos (CTO de Paradigm) a mentionné ce terme en 2021.

L’origine du mot monade est également intéressante. Dans le système philosophique du philosophe Leibniz, les Monades sont les éléments de base qui constituent l’univers. Ce sont des entités indivisibles qui ne sont pas affectées par la physique. Chaque Monade reflète l’univers entier et était autrefois traduite par « monade » en chinois.

En informatique, Monad est un modèle de conception dans les langages de programmation fonctionnels qui aide les programmeurs à gérer la complexité du monde réel avec une pureté presque mathématique, rendant le code plus modulaire, plus facile à comprendre et à maintenir.

Une autre chose intéressante est que Monad et Nomad sont des « anagrammes » l’un de l’autre. Nomad fait référence à nomade, et digital nomad fait référence à digital nomade/digital berger.

En plus des Monades, Georgios a également mentionné Sei et Polygon en discutant de ce sujet. Cependant, une autre raison importante pour laquelle il est si optimiste à propos de Parallel EVM est qu’ils ont développé un client Ethereum, Reth. Il se positionne comme un client de couche d’exécution Ethereum hautes performances, implémenté dans le langage Rust. Reth est développé à un rythme rapide et vient d’entrer dans la phase bêta. Peut-être qu’ils envisageront d’implémenter Parallel EVM directement sur Reth, mais compte tenu de la quantité d’ingénierie R&D, il pourrait être un meilleur choix d’investir dans d’autres équipes pour promouvoir Parallel EVM. Selon la documentation de Monad, ils utilisent principalement C++ et Rust en ingénierie.

Lorsque Reth a été lancé, il a également été accusé par les membres de l’équipe d’Erigon de plagier son code open source Akula, ce qui a également entraîné un manque de fonds et un arrêt du développement du projet Akula. Georgios a répondu que Reth n’est pas un fork d’un autre client, et que le code ne vient d’aucun autre client, mais qu’il est effectivement influencé et inspiré par Geth, Erigon et Akula. ()

Un autre participant principal est Jump Trading et Jump Capital. Le fondateur de Monad vient de Jump Trading et possède une riche expérience dans le trading à haute fréquence ; les investisseurs de Sei incluent Jump Capital, et Jump a été profondément impliqué dans l’écosystème Solana, y compris les infrastructures et les projets. .

Dragonfly, l’un des premiers investisseurs dans Monad, a également prêté attention aux pistes connexes.Il a investi dans NEAR, qui se concentre sur la technologie de sharding, ainsi que dans des chaînes publiques telles que Aptos, Avalanche et Nervos.

Mettre à jour l’algorithme de consensus ne suffit pas, c’est enfin au tour de la couche d’exécution

Au cours des dernières guerres de chaînes publiques, la couche d’exécution a été un endroit négligé et on ne parle presque que de l’innovation des algorithmes de consensus, qu’il s’agisse de Solana, Avalanche ou EOS. Bien qu’ils aient beaucoup d’innovations dans la couche d’exécution, la communauté se souvient encore de l’algorithme de consensus qu’elle a utilisé, et l’ensemble de la communauté pense également que la performance de ces chaînes publiques hautes performances vient de l’innovation de l’algorithme de consensus.

Mais ce n’est pas le cas : si l’on veut obtenir une chaîne publique performante, il faut faire correspondre l’algorithme de consensus et la couche d’exécution, ce qui correspond également aux défauts du tonneau en bois. Pour les chaînes publiques basées sur EVM et qui améliorent uniquement l’algorithme de consensus, des nœuds plus puissants sont nécessaires pour améliorer les performances. Par exemple, BSC limite le gaz pouvant être traité par un bloc au niveau de 2 000 TPS, ce qui nécessite une configuration de la machine plusieurs fois supérieure à l’investissement d’un nœud complet Ethereum. Polygon peut théoriquement atteindre 1 000 TPS, mais il ne s’agit généralement que de dizaines à centaines.

Les nœuds d’archives BSC nécessitent au moins un processeur à 16 cœurs et 128 Go de mémoire, et les nœuds Ethereum ne nécessitent qu’au moins un processeur à 4 cœurs et 16 Go de mémoire.

L’équipe BSC est consciente depuis longtemps de ces problèmes et travaille également avec NodeReal pour développer la technologie Parallel EVM. Ce n’est qu’ainsi que nous pourrons augmenter encore le nombre de transactions que chaque bloc peut traiter, permettre l’exécution d’un plus grand nombre de transactions en parallèle et augmenter la limite supérieure du TPS.

Parallélisme : pas seulement la mise à niveau d’un processeur monocœur vers un processeur multicœur

Dans la plupart des systèmes blockchain, les transactions sont exécutées de manière entièrement séquentielle. Vous pouvez le considérer comme un processeur monocœur. Le calcul suivant ne peut être effectué qu’une fois le calcul en cours terminé. Bien que cette méthode soit lente, ses avantages sont la simplicité et la faible complexité du système.

Mais si le futur système blockchain doit accéder à une échelle d’utilisateurs au niveau Internet, un processeur monocœur ne suffira certainement pas. Par conséquent, la mise à niveau vers une machine virtuelle parallélisée avec un processeur multicœur peut traiter plusieurs transactions en même temps et augmenter le débit. Cependant, la mise en œuvre de l’ingénierie présente de nombreux défis : par exemple, que dois-je faire si deux transactions traitées en même temps écrivent des données dans le même contrat intelligent ? Il est nécessaire de concevoir un nouveau mécanisme pour résoudre cette contradiction. Pour l’exécution parallèle d’autres contrats intelligents totalement indépendants, le débit peut être augmenté en fonction du nombre de threads de traitement parallèles et de l’échelle.

De plus, Parallel EVM améliore non seulement les capacités parallèles, mais optimise également l’efficacité d’exécution monothread. Keone Hon, PDG de Monad, a déclaré : “… le véritable goulot d’étranglement (de l’EVM) est la lecture et l’écriture fréquentes du statut lors du traitement des choses…”. Il a également déclaré que l’exécution parallèle n’est qu’une partie de la feuille de route et que la mission plus large de Monad est de se concentrer sur l’EVM et de le rendre aussi efficace que possible.

Par conséquent, bien que Parallel EVM signifie littéralement « parallélisation », il s’agit en fait d’une optimisation spéciale des performances de chaque composant d’EVM, ses efforts sont donc susceptibles de représenter la limite de performances selon la norme EVM.

EVM n’est pas égal à Solidité

La rédaction de contrats intelligents est une compétence essentielle pour la plupart des développeurs de blockchain. Les ingénieurs peuvent utiliser Solidity ou d’autres langages de contrats intelligents de haut niveau pour écrire des implémentations logiques correspondantes en fonction des besoins de l’entreprise. Cependant, l’EVM ne peut pas réellement comprendre directement la logique de Solidity. Il doit passer par une “traduction” et le traduire (compiler) dans un langage de bas niveau que la machine peut comprendre (code d’opération opcode / bytecode bytecode) avant de pouvoir être lu par la machine virtuelle. Les développeurs Solidity n’ont pas besoin de comprendre ce processus de traduction, car il existe déjà des outils matures pour le mettre en œuvre.

Après tout, il s’agit d’une “traduction”, il y aura donc également des frais généraux (surcharge supplémentaire). Les ingénieurs expérimentés dans le codage de bas niveau peuvent écrire la logique du programme directement à l’aide des opcodes dans Solidity, ce qui permet d’obtenir les performances les plus élevées, ce qui signifie que les utilisateurs peuvent économiser du gaz lors des transactions. Par exemple, le protocole Seaport lancé par Opensea utilise largement l’assemblage en ligne dans les contrats intelligents afin de réduire autant que possible les dépenses en gaz des utilisateurs.

Par conséquent, si Parallel EVM peut enfin être implémenté, il apportera non seulement des capacités de parallélisation, mais optimisera également les performances de l’ensemble de la pile EVM. Les développeurs d’applications ordinaires n’ont pas besoin de dépenser beaucoup d’énergie en optimisation juste pour économiser un peu de gaz, car la machine virtuelle sous-jacente est suffisamment puissante pour atténuer ces différences.

Les performances EVM varient et « standard » n’équivaut pas à « pratique d’ingénierie »

La « machine virtuelle » peut également être appelée « couche d’exécution ». C’est le moteur dans lequel les contrats intelligents sont finalement calculés et traités après avoir été compilés en opcodes. Le “bytecode” défini par la machine virtuelle Ethereum (EVM) est désormais devenu un standard de l’industrie. Qu’il s’agisse d’un réseau de deuxième couche basé sur Ethereum ou d’autres chaînes publiques indépendantes, ils sont plus disposés à être directement et entièrement compatibles avec l’EVM. standard avant le développement. Les auteurs peuvent rédiger des contrats intelligents une seule fois et les déployer sur plusieurs réseaux, ce qui est extrêmement rentable.

Par conséquent, tant qu’il est entièrement compatible avec la norme « bytecode » d’EVM, il peut être appelé EVM, mais les méthodes de mise en œuvre peuvent varier considérablement. Par exemple, le client Ethereum Geth utilise le langage Go pour implémenter la norme EVM. Cependant, Ipsilon, l’équipe de recherche sur la couche d’exécution de la Fondation Ethereum, maintient une implémentation indépendante d’EVM développée en C++. D’autres clients Ethereum peuvent directement appeler cette bibliothèque pour l’exécuter en tant qu’EVM.

Par exemple, de nombreux produits fabriqués industriellement ont des normes internationales correspondantes. Par exemple, lorsqu’un produit quitte l’usine, le nombre de colonies doit être inférieur à une certaine valeur avant de pouvoir être vendu. C’est la « norme ». Mais comment répondre à cette norme d’usine, chaque usine peut choisir parmi des dizaines de méthodes de stérilisation différentes, et certaines usines peuvent trouver des moyens plus rentables de répondre à cette exigence.

Puisqu’il existe une implémentation d’evmone, d’autres implémentations peuvent également être réalisées. Ainsi, dans cet exemple d’EVM, la norme EVM définit certaines méthodes de fonctionnement de base “bytecode” (telles que la prise en charge de l’arithmétique la plus élémentaire telle que l’addition, la soustraction, la multiplication, etc.). Lorsque chaque bytecode a une certaine entrée, il y a une sortie définie. . Lorsqu’il s’agit de répondre à ce critère, les implémentations (et les pratiques) varient considérablement, avec une grande marge de personnalisation et des possibilités d’optimisation technique.

Similitudes et différences de l’EVM parallèle

Dans la piste Parallel EVM, en plus du Monad le plus populaire, il y a aussi Sei, MegaETH, Polygon, Neon EVM, BSC, etc., et le client Reth de Paradigm souhaite également implémenter des fonctions de parallélisation.

Du point de vue du positionnement, Monad, Sei, Polygon et BSC sont toutes des blockchains de couche 1, tandis que MegaETH peut être de couche 2. Neon EVM est basé sur le réseau Solana. De plus, Reth est un client open source et MegaETH continuera à être développé en partie sur la base des projets Reth.

Bien sûr, il y a toujours une concurrence entre ces équipes, et tous les détails techniques et documents d’ingénierie n’ont pas été entièrement divulgués. D’autres comparaisons devront attendre jusqu’à ce qu’elles soient progressivement divulguées. Cela ressemble peut-être à nouveau à une course aux armements, comme BTC Layer 2, Resttaking et Ethereum Layer 2. Bien qu’il existe des différences subtiles entre les technologies (et l’open source), le plus important est de savoir comment construire le caractère unique de l’écosystème.

Difficultés techniques de Parallel EVM

Pour les transactions exécutées séquentiellement, le goulot d’étranglement est le processeur et le processus de lecture et d’écriture de l’état. Mais l’avantage est que cette méthode est assez simple, sans erreur et que toutes les tâches peuvent être accomplies étape par étape. Pour les machines virtuelles qui s’exécutent en parallèle, il peut y avoir des conflits d’état, cette partie du jugement doit donc être ajoutée avant ou après l’exécution.

Un exemple simple est que si la machine virtuelle prend en charge l’exécution parallèle de quatre threads et que chaque thread peut traiter une transaction en même temps, si ces quatre transactions sont toutes des transactions avec le même pool de transactions sur Uniswap, elles ne peuvent pas être exécutées en parallèle. Calcul, car chaque transaction affectera le prix de transaction de ce pool de transactions. Mais si ces quatre threads travaillent simultanément sur quatre choses totalement indépendantes, alors il n’y a pas de problème.

Cela impliquera la conception et la mise en œuvre de l’ingénierie par différentes équipes, mais il faut au moins s’assurer qu’après une exécution parallèle, un module est nécessaire pour détecter les conflits et réexécuter si des conflits sont rencontrés. Bien entendu, si les transactions susceptibles d’entrer en conflit peuvent être prédites et filtrées à l’avance, l’efficacité parallèle de l’ensemble de la machine virtuelle peut également être augmentée.

En plus des différences dans la mise en œuvre technique de la machine virtuelle Parallel EVM, chaque équipe repensera et améliorera généralement les performances de lecture et d’écriture de la base de données d’état, et concevra un algorithme de consensus, tel que MonadDb et MonadBFT conçus par Monad.

défi

Pour Parallel EVM, il y a deux défis possibles : la question de savoir si la valeur technique à long terme sera captée par Ethereum ; et la centralisation des nœuds.

Étant donné que diverses équipes sont encore en phase de développement et de test de la technologie Parallel EVM, elles n’ont pas encore choisi d’ouvrir tous les détails d’ingénierie en open source. Cependant, après être entrés dans le réseau de test et le réseau principal, ces documents de projet seront rendus publics et pourront également être absorbés par Ethereum ou d’autres chaînes publiques. Il est donc nécessaire à ce moment-là de promouvoir plus rapidement la construction écologique et de construire davantage de douves écologiques.

Cependant, ce problème n’est pas si grave : d’une part, pour les développeurs de Crypto, il existe désormais davantage de licences open source parmi lesquelles choisir (comme la licence d’Uniswap qui peut rendre le code public mais ne permet pas de se lancer dans des projets commerciaux). en revanche, le positionnement de Monad est intrinsèquement différent de celui d’Ethereum. Même si Ethereum peut atteindre la finalité d’un socket unique (SSF) à l’avenir, la finalité des transactions sera toujours d’au moins 12 secondes, ce qui est loin d’être suffisant pour des scénarios d’application à plus haute fréquence.

Un autre défi commun à toutes les chaînes publiques hautes performances est de savoir comment déployer davantage de nœuds pour répondre aux exigences de base des utilisateurs en matière de sans autorisation et de confiance : la décentralisation. Peut-être que certains indicateurs peuvent être quantifiés, tels que « TPS divisé par les exigences matérielles du nœud », afin que nous puissions contrôler les variables et comparer quelle chaîne publique/client a un TPS plus élevé en fonction des exigences matérielles spécifiques. Après tout, plus les exigences matérielles d’un nœud sont faibles, plus le nombre de nœuds possibles est élevé.

Ensuite, nous continuerons à suivre l’avancement de chaque projet Parallel EVM et à discuter en détail de leurs technologies et de leurs différences.