TL;DR

1. 1. Plusieurs grands VC, dont Paradigm, Jump et Dragonfly, investissent dans le concept de Parallel EVM.
2. 1. Les projets représentatifs de ce domaine comprennent Monad, Sei, MegaETH, Polygon, Neon EVM et BSC, fonctionnant à la fois sur les solutions de couche 1 (L1) et de couche 2 (L2).
3. 1. Cependant, il existe peu d'informations publiques disponibles concernant les différences spécifiques entre les équipes.
4. 1. Alors que "parallélisation" est le sens littéral de Parallel EVM, il désigne une optimisation spécialisée visant à améliorer divers aspects de la performance de l'EVM, repoussant potentiellement les limites des capacités de l'EVM.
5. 1. Les défis incluent le besoin de refactoriser l'ensemble de la pile technologique et de résoudre des problèmes tels que prédire les conflits entre les transactions parallèles et gérer efficacement les conflits s'ils surviennent.
6. 1. Un autre défi consiste à établir une différenciation dans l'écosystème open-source tout en équilibrant la décentralisation avec les performances.

Après des recherches approfondies et des itérations sur les algorithmes de consensus, les couches de données (DA) et la technologie de preuve de connaissance nulle, l'attention s'est tournée vers la prochaine frontière de la technologie de pointe : l'EVM parallèle. Cette tendance a déjà attiré d'importants investissements du marché financier, avec des centaines de millions de dollars injectés dans le développement de plusieurs startups de niveau licorne.

Le projecteur sur Parallel EVM, également connu sous le nom de parallélisation EVM, a pris de l'ampleur lorsque Georgios Konstantopoulos, CTO de Paradigm, et Haseeb Qureshi de Dragonfly ont mis en lumière ce concept de manière fortuite à la fin de 2023 tout en discutant des tendances futures pour 2024. Malgré cette attention, les discussions détaillées sur le sujet ont été rares, ce qui a conduit beaucoup à le considérer comme quelque chose de particulièrement novateur. Étant donné que la Machine Virtuelle Ethereum (EVM) et le calcul parallèle sont des concepts bien établis, ce qui élève la fusion de ces deux termes au statut de tendance émergente importante reste flou.

Cependant, Parallel EVM reste un sujet hautement spécialisé. Il est à noter que dans les résumés annuels et les prévisions de tendances de nombreuses institutions de recherche, Parallel EVM n'est pas mentionné. Par conséquent, il reste un concept naissant manquant de consensus généralisé. De plus, semblable à des concepts tels que les algorithmes de consensus et les applications décentralisées (DA), Parallel EVM est intrinsèquement technique, limitant ainsi son public à un champ encore plus restreint.

Le principal avantage de Parallel EVM réside dans sa capacité à permettre aux applications décentralisées existantes d'atteindre des niveaux de performance comparables à ceux d'Internet. En fait, on pourrait soutenir que Parallel EVM se distingue en tant que technologie novatrice capable d'exploiter une vaste gamme de contrats intelligents établis tout en réalisant des performances élevées et un débit parallèle sur les chaînes publiques.

Paradigm a hâte d'entrer dans le jeu depuis longtemps, Jump investit massivement

Le magazine "Fortune" rapporte que Paradigm a l'intention de diriger le dernier tour de financement de Monad, visant à lever 200 millions de dollars avec une valorisation de 3 milliards de dollars. Alors que cela marque la première incursion de Paradigm dans le soutien à une équipe avec un concept EVM parallèle, ils suivent de près cette technologie depuis plusieurs années. Georgios Konstantopoulos, CTO de Paradigm, a mentionné ce terme pour la première fois en 2021.

L'étymologie de « Monade » ajoute une autre couche d'intrigue. Dans le système du philosophe Leibniz, la Monade signifie l'élément fondamental constituant l'univers. Ces entités indivisibles restent impénétrables aux influences physiques, chacune reflétant la totalité de l'univers, connue sous le nom de « 单子 » en chinois.

Dans le domaine de l'informatique, le Monad sert de modèle de conception au sein des langages de programmation fonctionnelle, aidant les programmeurs à naviguer dans les complexités du monde réel avec une précision quasi mathématique. Cette approche favorise la modularité du code, la compréhension et la maintenance.

Un fait notable est la symétrie linguistique entre Monad et Nomad, ce dernier désignant un vagabond, et "nomade numérique" faisant référence à un vagabond dans la sphère numérique.

Georgios, dans son discours sur le sujet, a également cité Sei et Polygon. Cependant, son optimisme à l'égard du Parallel EVM est renforcé par le développement de Reth, un client Ethereum conçu par Paradigm. Positionné comme un client de couche d'exécution Ethereum haute performance construit en Rust, Reth progresse rapidement et est récemment passé à l'étape Beta. Bien que la perspective d'intégrer directement le Parallel EVM dans Reth soit envisagée, l'effort d'ingénierie considérable impliqué suggère que soutenir le Parallel EVM par des investissements dans d'autres équipes pourrait être une option plus viable. La documentation de Monad révèle leur utilisation prédominante du C++ et du Rust dans leurs efforts d'ingénierie.

À la création de Reth, des accusations ont émergé de la part des membres de l'équipe d'Erigon, alléguant un plagiat de leur code source ouvert, Akula, entraînant une diminution des financements pour le projet Akula. Georgios a réfuté ces allégations, affirmant que Reth n'est ni un dérivé ni un fork d'un autre client, même s'il s'inspire de Geth, Erigon et Akula.

Un autre acteur clé est Jump Trading et Jump Capital, avec le fondateur de Monad originaire de Jump Trading, bénéficiant d'une vaste expérience dans le trading haute fréquence. Sei compte Jump Capital parmi ses investisseurs, avec une implication profonde de Jump dans l'écosystème Solana, couvrant l'infrastructure et les projets.

Dragonfly, un investisseur précoce dans Monad, a également gardé un œil attentif sur les développements connexes, avec des investissements dans NEAR, se concentrant sur la technologie de sharding, aux côtés de Aptos, Avalanche, Nervos et d'autres chaînes publiques.

Mettre à niveau les algorithmes de consensus ne suffit pas, c'est enfin le tour de la couche d'exécution

Lors des récentes batailles entre chaînes publiques, le feu des projecteurs a régulièrement contourné la couche d'exécution, se fixant presque exclusivement sur des algorithmes de consensus innovants, qu'il s'agisse de Solana, Avalanche ou EOS, entre autres. Malgré des innovations significatives dans la couche d'exécution de ces chaînes, la communauté a tendance à se rappeler principalement de leurs algorithmes de consensus utilisés. De plus, il existe une idée répandue au sein de la communauté selon laquelle les performances supérieures de ces chaînes publiques à haut débit proviennent uniquement de leurs algorithmes de consensus révolutionnaires.

Cependant, la réalisation d'une chaîne publique haute performance nécessite une relation symbiotique entre l'algorithme de consensus et la couche d'exécution, répétant le principe selon lequel une chaîne n'est aussi forte que son maillon le plus faible. Les chaînes publiques dépendantes de la Machine Virtuelle Ethereum (EVM), et se concentrant uniquement sur l'amélioration de leur algorithme de consensus, rencontrent des goulots d'étranglement de performance qui exigent des nœuds de plus en plus robustes. Prenons par exemple la Binance Smart Chain (BSC), qui limite le traitement du gaz de bloc à 2000 transactions par seconde (TPS). Pour prendre en charge cela, les configurations des nœuds doivent dépasser celles d'un nœud complet Ethereum de plusieurs fois. Alors que Polygon revendique théoriquement une capacité de 1000 TPS, il n'atteint généralement que des dizaines à des centaines.

Les nœuds d'archive BSC nécessitent un minimum de 16 cœurs de CPU et 128 Go de mémoire, comparé aux nœuds Ethereum, qui nécessitent au moins 4 cœurs de CPU et 16 Go de mémoire.

Reconnaissant ces défis, l'équipe de BSC a conclu une collaboration avec NodeReal pour développer la technologie Parallel EVM. Cette innovation vise à améliorer davantage le débit des transactions par bloc en permettant l'exécution parallèle des transactions, ce qui élève par conséquent la limite supérieure des TPS.

Parallèle : passage d'un CPU monocœur à un CPU multicœur

Dans la plupart des systèmes de blockchain, les transactions suivent un ordre séquentiel strict, similaire à un processeur à un seul cœur où chaque calcul doit attendre que le précédent se termine. Malgré sa simplicité et sa faible complexité système, cette approche est relativement lente.

Cependant, alors que les futurs systèmes blockchain visent à accueillir des bases d'utilisateurs à l'échelle d'Internet, le recours exclusif à un CPU monocœur devient insuffisant. Par conséquent, passer à un CPU multicœur avec des machines virtuelles parallélisées permet le traitement simultané de plusieurs transactions, augmentant ainsi le débit. Cependant, l'ingénierie de cette mise à niveau présente de nombreux défis, tels que la gestion des conflits lorsque deux transactions traitées simultanément tentent de modifier le même contrat intelligent. Pour y remédier, il est nécessaire de développer de nouveaux mécanismes.

Pour les contrats intelligents non liés exécutés en parallèle, le débit peut être encore augmenté en fonction du nombre de threads de traitement simultanés. De plus, l'EVM parallèle augmente non seulement les capacités parallèles, mais améliore également l'efficacité de l'exécution sur un seul thread. Keone Hon, PDG de Monad, a souligné que le principal goulot d'étranglement de l'EVM réside dans les lectures et écritures fréquentes des états. Il a souligné que si l'exécution parallèle est un aspect essentiel de la feuille de route, l'objectif principal de Monad est d'optimiser l'efficacité de l'EVM à son maximum.

Ainsi, bien que l'EVM parallèle implique intrinsèquement une "parallélisation", il sert principalement d'optimisation spécialisée des performances de divers composants de l'EVM. Par conséquent, ses efforts délimitent probablement les limites de performance dans la norme EVM.

EVM n'est pas égal à Solidity

Écrire des contrats intelligents est une compétence vitale pour les développeurs de blockchain, nécessitant la capacité d'implémenter une logique basée sur les exigences commerciales en utilisant Solidity ou d'autres langages de haut niveau. Cependant, la Machine Virtuelle Ethereum (EVM) ne comprend pas directement la logique Solidity ; elle nécessite une traduction en bytecode de bas niveau pour l'exécution. Les développeurs Solidity s'appuient généralement sur des outils existants pour gérer ce processus de traduction.

Cette traduction entraîne des frais généraux, mais les ingénieurs familiers avec le code de bas niveau peuvent le contourner en codant directement la logique à l'aide d'opcodes en Solidity, ce qui permet une efficacité optimale et des économies de gaz pour les transactions des utilisateurs. Par exemple, le protocole Seaport d'Opensea utilise abondamment l'assemblage en ligne dans les contrats intelligents pour minimiser les coûts de gaz pour les utilisateurs.

La mise en œuvre potentielle de Parallel EVM promet non seulement d'introduire des capacités parallèles, mais aussi d'optimiser les performances globales de la pile EVM. Cette avancée soulagerait la nécessité pour les développeurs d'applications de consacrer des efforts importants à l'optimisation du gaz, car la machine virtuelle sous-jacente gérerait déjà efficacement de telles différences.

Différences de performance de l'EVM, « Standard » ne signifie pas « Pratique d'ingénierie »

Le moteur où les contrats intelligents sont compilés en opcodes et traités est souvent appelé la "couche d'exécution" ou la "machine virtuelle". Le bytecode établi par la Machine Virtuelle Ethereum (EVM) est devenu une norme de l'industrie. Que ce soit sur les réseaux de couche 2 d'Ethereum ou sur d'autres chaînes publiques indépendantes, la compatibilité avec la norme EVM est très appréciée. Les développeurs bénéficient de la possibilité d'écrire un contrat intelligent une fois et de le déployer sur plusieurs réseaux, ce qui entraîne des économies de coûts considérables.

Bien que le respect de la norme du bytecode EVM qualifie un système de compatible avec l'EVM, 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, tandis que l'équipe de recherche de la Fondation Ethereum, Ipsilon, maintient une implémentation indépendante de l'EVM développée en C++. D'autres clients Ethereum peuvent utiliser directement cette implémentation en tant que moteur d'exécution EVM.

De manière analogue, diverses industries respectent les normes internationales pour leurs produits. Par exemple, un produit doit respecter un seuil spécifique de comptage bactérien avant de pouvoir être vendu, représentant la "norme". Cependant, les usines individuelles peuvent utiliser diverses méthodes de stérilisation pour répondre à cette exigence, certaines optant pour des approches plus rentables, illustrant la "pratique".

L'existence de mises en œuvre telles que evmone indique la faisabilité d'approches alternatives. Par conséquent, dans le contexte de l'EVM, la norme délimite les opérations fondamentales des octets de code (par exemple, les fonctions arithmétiques de base telles que l'addition, la soustraction, la multiplication), chaque octet de code donnant des sorties spécifiques en fonction des entrées définies. Bien que le respect de cette norme soit essentiel, les méthodologies utilisées dans la pratique peuvent varier largement, offrant ainsi une ample marge de personnalisation et d'optimisation de l'ingénierie.

Similarités et différences de Parallel EVM

Dans la piste Parallel EVM, outre le Monad largement connu, d'autres candidats importants incluent Sei, MegaETH, Polygon, Neon EVM, BSC et le client Reth de Paradigm, qui s'efforce également d'intégrer la parallélisation.

En termes de leur positionnement, Monad, Sei, Polygon et BSC sont catégorisés comme des blockchains de couche 1, tandis que MegaETH pourrait potentiellement fonctionner comme une solution de couche 2, et Neon EVM opère dans le cadre du réseau Solana. De plus, Reth se distingue en tant que client open-source, MegaETH étant prêt à poursuivre son développement en utilisant certains aspects de l'ingénierie de Reth.

Naturellement, il existe une concurrence entre ces équipes, et les spécifications techniques complètes et la documentation technique n'ont pas encore été entièrement divulguées. D'autres comparaisons devront attendre les révélations progressives à l'avenir. Cette dynamique peut ressembler à une course aux armements similaire aux développements observés dans BTC Layer 2, Restaking et Ethereum Layer 2. Malgré des distinctions techniques nuancées et la nature open source de ces projets, le facteur crucial réside dans l'établissement de la distinction de chaque écosystème.

Défis techniques de l'EVM parallèle

Le goulot d'étranglement dans les transactions exécutées séquentiellement provient des opérations CPU et du processus de lecture et d'écriture des états. Cependant, cette méthode offre simplicité, précision et la capacité d'exécuter des transactions étape par étape. En revanche, les machines virtuelles exécutées en parallèle peuvent rencontrer des conflits d'états, nécessitant des vérifications supplémentaires avant ou après l'exécution.

Considérez un scénario où une machine virtuelle prend en charge quatre threads pour une exécution parallèle, chaque thread étant capable de traiter une transaction simultanément. Si les quatre transactions impliquent le même pool de transactions sur Uniswap, le calcul parallèle est impossible en raison de l'impact potentiel sur le prix des transactions du pool. Cependant, si ces threads gèrent des tâches totalement indépendantes, l'exécution parallèle ne pose aucun problème.

La résolution des conflits potentiels après l'exécution parallèle nécessite un module dédié pour la détection des conflits et la ré-exécution en cas de conflits. De plus, le dépistage préventif des transactions potentiellement conflictuelles peut renforcer l'efficacité parallèle globale de la machine virtuelle.

Outre les mises en œuvre d'ingénierie spécifiques à Parallel EVM, les équipes se concentrent généralement sur la refonte et l'optimisation des performances de lecture/écriture de la base de données d'état. De plus, elles élaborent des algorithmes de consensus tels que Monad's MonadDb et MonadBFT.

Défis

Pour Parallel EVM, deux défis potentiels émergent : la capture de la valeur d'ingénierie à long terme par Ethereum et la centralisation des nœuds.

Actuellement, diverses équipes se trouvent dans les phases de développement et de test de la technologie EVM parallèle, aucune n'ayant encore choisi de rendre open source tous les détails d'ingénierie, ce qui constitue un obstacle actuel. Cependant, une fois intégrées dans le testnet et le mainnet, ces spécifications d'ingénierie deviendront publiques et pourraient potentiellement être intégrées par Ethereum ou d'autres chaînes publiques. Par conséquent, il est nécessaire d'accélérer le développement de l'écosystème et d'établir des barrières supplémentaires au niveau de l'écosystème.

Néanmoins, ce problème ne constitue pas un obstacle insurmontable. D'une part, les développeurs de crypto disposent désormais d'un éventail plus large de licences open-source à choisir (comme le modèle de licence d'Uniswap, permettant la divulgation du code mais restreignant le fork vers des projets commerciaux). D'autre part, la position de Monad diffère de celle d'Ethereum. Même si Ethereum atteint une finalité à un seul slot (SSF) à l'avenir, la finalité des transactions reste d'au moins 12 secondes, insuffisante pour les cas d'utilisation à haute fréquence.

Un autre défi partagé parmi les chaînes publiques à haute performance est le déploiement de nœuds supplémentaires pour satisfaire les prérequis fondamentaux de la permission des utilisateurs et de la non-confiance : la décentralisation. Il pourrait être possible de quantifier certaines mesures, telles que "TPS divisé par les exigences matérielles des nœuds," permettant une analyse comparative pour déterminer quelle chaîne publique/client offre un TPS plus élevé sous des prérequis matériels spécifiques. En fin de compte, des exigences matérielles plus faibles pour les nœuds facilitent un déploiement de nœuds plus important.

À l'avenir, nous continuerons de surveiller les progrès de divers projets associés à Parallel EVM et d'étudier en détail leurs technologies et leurs divergences.

Avertissement：

1. Cet article est repris de [ Gate.io ]Recherche ChainFeeds], Tous les droits d'auteur appartiennent à l'auteur original [ZHIXIONG PAN]. Si des objections sont soulevées concernant cette reproduction, 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, il est interdit de copier, distribuer ou plagier les articles traduits.