Libérer les performances d'Ethereum : une voie innovante au-delà des goulots d'étranglement de l'EVM
TechFlow SélectionTechFlow Sélection
Libérer les performances d'Ethereum : une voie innovante au-delà des goulots d'étranglement de l'EVM
L'EVM peut-elle relever le défi des applications hautes performances ?
Dédié à des analyses Web3 approfondiesAuteur : Siddharth Rao, IOSG Ventures
Sur les performances de la Machine Virtuelle Ethereum (EVM)
Chaque opération sur le réseau principal d’Ethereum coûte une certaine quantité de gaz. Si nous devions exécuter intégralement sur la chaîne toute la puissance de calcul nécessaire aux applications basiques, soit l’application planterait, soit l’utilisateur ferait faillite.
Cela a donné naissance aux solutions de couche 2 (L2) : OPRU introduit des séquenceurs pour regrouper un ensemble de transactions, puis les soumettre à la chaîne principale. Cela permet non seulement aux applications de bénéficier de la sécurité d’Ethereum, mais améliore aussi l’expérience utilisateur. Les utilisateurs peuvent soumettre leurs transactions plus rapidement et à moindre coût. Bien que les opérations soient ainsi moins chères, elles utilisent toujours l’EVM native comme couche d’exécution. De même que pour les Rollups à base de ZK, Scroll et Polygon zkEVM utilisent ou utiliseront des circuits zk fondés sur l’EVM, où une preuve zk sera générée pour chaque transaction ou lot de transactions exécutées sur leur système de vérification. Bien que cela permette aux développeurs de construire des applications entièrement « on-chain », ces systèmes peuvent-ils toutefois exécuter efficacement et économiquement des applications hautes en performance ?
Quelles sont ces applications hautes en performance ?
On pense immédiatement aux jeux, aux carnets d’ordres on-chain, au Web3 social, à l’apprentissage automatique, à la modélisation génomique, etc. Toutes ces applications exigent une grande puissance de calcul, dont l’exécution sur L2 reste très coûteuse. Un autre problème de l’EVM est que sa vitesse et son efficacité computationnelles sont inférieures à celles d’autres systèmes modernes tels que SVM (Sealevel Virtual Machine).
Bien que les EVM de couche 3 (L3) puissent réduire le coût du calcul, la structure même de l’EVM n’est peut-être pas optimale pour exécuter des tâches intensives, car elle ne supporte pas l’exécution parallèle. À chaque fois qu’une nouvelle couche est ajoutée, afin de préserver l’esprit de décentralisation, il faut construire une nouvelle infrastructure (un nouveau réseau de nœuds), ce qui nécessite toujours autant de fournisseurs pour s’échelonner, ou bien un tout nouveau groupe de fournisseurs de nœuds (particuliers/entreprises) apportant des ressources, voire les deux.
Ainsi, chaque fois qu’une solution plus avancée est développée, l’infrastructure existante doit être mise à niveau, ou alors une nouvelle couche est créée par-dessus. Pour résoudre ce problème, nous avons besoin d’une infrastructure de calcul post-sécurité quantique, décentralisée, sans confiance et haute performance, capable d’utiliser efficacement des algorithmes quantiques pour le calcul dans les applications décentralisées.
Des alt-L1 comme Solana, Sui et Aptos parviennent à exécuter des opérations en parallèle, mais en raison de la morosité du marché, du manque de liquidités et de développeurs, ils ne constituent pas une menace sérieuse pour Ethereum. Le manque de confiance, combiné à la formidable barrière de protection qu’Ethereum a établie grâce à son effet réseau, fait qu’à ce jour, aucun « tueur » d’ETH/EVM n’existe. La vraie question ici est la suivante : Pourquoi tous les calculs devraient-ils être effectués on-chain ? Existe-t-il un système d’exécution alternatif, tout aussi sans confiance et décentralisé ? C’est exactement ce que permet le système DCompute.
L’infrastructure DCompute doit être décentralisée, sécurisée contre les ordinateurs quantiques, et sans confiance ; elle ne devrait pas être, ou du moins pas nécessairement, une technologie blockchain/distribuée. Toutefois, la vérification des résultats de calcul, la transition correcte d’état et la confirmation finale sont essentielles. Tel est précisément le fonctionnement des chaînes EVM : tout en maintenant la sécurité et l’immutabilité du réseau, le calcul décentralisé, sans confiance et sécurisé peut être déplacé hors chaîne.
Ce que nous négligeons ici principalement, c’est la question de la disponibilité des données. Cet article ne sous-estime pas l’importance de la disponibilité des données, car des solutions comme Celestia et EigenDA progressent déjà dans cette direction.
1 : Externalisation uniquement du calcul (Only Compute Outsourced)
2. Externalisation du calcul et de la disponibilité des données
En examinant le type 1, les rollups zk font déjà cela, mais ils sont soit limités par l’EVM, soit obligent les développeurs à apprendre un nouveau langage ou jeu d’instructions. La solution idéale devrait être efficace, économique (en coût et ressources), décentralisée, privée et vérifiable. Des preuves ZK peuvent être construites sur des serveurs AWS, mais elles ne sont pas décentralisées. Des projets comme Nillion et Nexus tentent de résoudre le problème du calcul général de manière décentralisée. Toutefois, ces solutions ne sont pas vérifiables, en l’absence de preuves ZK.
Le type 2 combine un modèle de calcul hors chaîne avec une couche de disponibilité des données séparée, mais le calcul doit encore être validé sur la chaîne.
Examinons différents modèles de calcul décentralisé disponibles aujourd’hui, allant de partiellement fiables à potentiellement totalement sans confiance.
Autres systèmes de calcul (Alternative Computation Systems)
Cartographie de l’écosystème de calcul externalisé d’Ethereum
- Calcul dans enceintes sécurisées (Secure Enclave Computations) / Environnements d’exécution fiables (Trusted Execution Environments - TEE)
Un TEE (environnement d’exécution fiable) est comme une boîte spéciale à l’intérieur d’un ordinateur ou d’un smartphone. Elle possède ses propres verrous et clés, et seules certaines applications (appelées applications fiables) peuvent y accéder. Lorsqu’une application fiable s’exécute à l’intérieur d’un TEE, elle est protégée contre les autres programmes, voire contre le système d’exploitation lui-même.
C’est comme un abri secret accessible uniquement à quelques amis triés sur le volet. L’exemple le plus courant de TEE est la zone de sécurité (secure enclave), présente dans nos appareils, comme la puce T1 d’Apple ou SGX d’Intel, utilisée pour exécuter des opérations critiques telles que FaceID.
Étant donné que les TEE sont des systèmes isolés, le processus d’authentification ne peut pas être compromis — du moins en théorie, car il repose sur une hypothèse de confiance. On peut imaginer une porte de sécurité : vous croyez qu’elle est sûre parce qu’Intel ou Apple l’a construite, mais il existe suffisamment d’acteurs malveillants (hackers ou autres ordinateurs) capables de fracturer cette porte. Les TEE ne sont pas « sécurisés contre les ordinateurs quantiques », ce qui signifie qu’un ordinateur quantique disposant de ressources illimitées pourrait briser la sécurité d’un TEE. Comme les ordinateurs deviennent de plus en plus puissants, nous devons impérativement tenir compte de la sécurité post-quantique lors de la conception de systèmes de calcul et de schémas cryptographiques durables.
- Calcul multipartite sécurisé (SMPC)
Le SMPC (calcul multipartite sécurisé) est également une approche bien connue des acteurs de la technologie blockchain. Dans un réseau SMPC, le flux de travail suit généralement trois étapes principales :
-
Étape 1 : Convertir les entrées du calcul en parts (shares) distribuées entre les nœuds SMPC.
-
Étape 2 : Réaliser le calcul proprement dit, impliquant généralement des échanges de messages entre les nœuds SMPC. À la fin de cette étape, chaque nœud détient une part de la valeur de sortie.
-
Étape 3 : Envoyer les parts du résultat à un ou plusieurs nœuds de sortie, qui exécutent un algorithme de récupération du secret (LSS) pour reconstituer le résultat final.
Imaginez une chaîne de montage automobile : la fabrication des composants (moteur, portes, rétroviseurs) est externalisée vers des équipementiers (OEM — nœuds de travail), puis une ligne d’assemblage assemble tous les éléments pour fabriquer la voiture (nœuds de résultat).
La répartition secrète (secret sharing) est cruciale pour les modèles de calcul décentralisés protégeant la vie privée. Elle empêche tout participant unique d’obtenir le « secret » complet (ici, les entrées) et de produire intentionnellement un résultat erroné. Le SMPC pourrait bien être l’un des systèmes décentralisés les plus simples et les plus sûrs. Bien qu’aucun modèle complètement décentralisé n’existe encore à ce jour, cela reste logiquement possible.
Des fournisseurs MPC comme Sharemind offrent une infrastructure MPC pour le calcul, mais restent centralisés. Comment garantir la confidentialité ? Comment s’assurer que le réseau (ou Sharemind lui-même) n’agit pas de façon malveillante ? C’est là qu’interviennent les preuves zk et le calcul zk vérifiable.
- Nil Message Compute (NMC)
Le NMC est une nouvelle méthode de calcul distribué développée par l’équipe de Nillion. Il s’agit d’une évolution du SMPC où les nœuds n’ont pas besoin d’interagir ni d’échanger des messages pendant le calcul. Pour cela, ils utilisent une primitive cryptographique appelée masquage à usage unique (One-Time Masking), qui utilise une série de nombres aléatoires appelés facteurs d’aveuglement (blinding factors) pour masquer un secret, similaire au chiffrement de Vernam. L’objectif du OTM est d’assurer la correction de manière efficace, ce qui signifie que les nœuds NMC n’ont aucun message à échanger pour exécuter le calcul. Par conséquent, le NMC ne connaît pas les problèmes d’évolutivité du SMPC.
- Calcul vérifiable à connaissance nulle (ZK Verifiable Computation)
Le calcul vérifiable à connaissance nulle (ZKVC) consiste à générer une preuve à connaissance nulle pour un ensemble d’entrées et une fonction donnée, prouvant ainsi que tout système exécutant ce calcul le fait correctement. Bien que le calcul ZK vérifiable soit encore à ses débuts, il constitue déjà une pièce maîtresse de la feuille de route d’extension d’Ethereum.
Les preuves ZK existent sous diverses formes (comme illustré ci-dessous, selon le document « Off-Chaining_Models ») :
Nous avons maintenant une compréhension de base des différentes implémentations des preuves ZK. Quelles conditions sont nécessaires pour utiliser une preuve ZK afin de valider un calcul ?
-
Premièrement, il faut choisir une primitive de preuve. Une primitive idéale serait peu coûteuse à produire, peu gourmande en mémoire et facile à vérifier.
-
Deuxièmement, choisir un circuit zk, conçu pour générer la preuve via le calcul.
-
Troisièmement, exécuter le calcul donné sur un système/réseau spécifique, à partir des entrées fournies, pour obtenir la sortie.
Le dilemme des développeurs – L’efficacité des preuves
Un autre point important est que la construction de circuits reste très difficile. Déjà, demander aux développeurs d’apprendre Solidity n’est pas chose aisée ; maintenant, leur imposer d’apprendre Circom pour construire des circuits, ou un langage spécifique (comme Cairo) pour développer des apps zk, semble presque irréaliste.
Comme le montrent les statistiques ci-dessus, adapter l’environnement Web3 aux développeurs semble plus durable que d’essayer d’attirer les développeurs vers un nouvel environnement de développement Web3.
Si les ZK sont l’avenir du Web3, les applications Web3 doivent pouvoir être construites à l’aide des compétences existantes des développeurs. Ainsi, les circuits zk doivent être conçus pour générer des preuves à partir d’algorithmes écrits en JavaScript, Rust, ou autres langages courants.
De telles solutions existent. Deux équipes viennent à l’esprit : RiscZero et Lurk Labs. Ces deux équipes partagent une vision très similaire : permettre aux développeurs de créer des apps zk sans franchir une courbe d’apprentissage abrupte.
Lurk Labs en est encore à un stade précoce, mais l’équipe travaille sur ce projet depuis longtemps. Ils se concentrent sur la génération de preuves Nova via des circuits universels. La preuve Nova a été proposée par Abhiram Kothapalli de l’Université Carnegie Mellon, Srinath Setty de Microsoft Research et Ioanna Tziallae de l’Université de New York. Comparée à d’autres systèmes SNARK, la preuve Nova présente un avantage particulier pour le calcul incrémentalement vérifiable (IVC). L’IVC (Incrementally Verifiable Computation) est un concept en informatique et cryptographie visant à valider un calcul sans devoir le recalculer entièrement depuis le début. Lorsque le calcul est long et complexe, les preuves doivent être optimisées pour l’IVC.
La preuve Nova n’est pas « prête à l’emploi » comme d’autres systèmes de preuve. Nova n’est qu’une astuce de pliage (folding trick) ; les développeurs ont encore besoin d’un système de preuve pour produire la preuve finale. C’est pourquoi Lurk Labs a créé Lurk Lang, une implémentation LISP. Étant donné que LISP est un langage de bas niveau, il est facile de générer des preuves sur des circuits universels, et également facile de transpiler vers JavaScript, ce qui permettrait à Lurk Labs de toucher les 17,4 millions de développeurs JavaScript. D’autres langages universels comme Python peuvent aussi être transpilés.
En résumé, la preuve Nova semble être une primitive de preuve remarquable. Bien que sa taille augmente linéairement avec celle du calcul, elle laisse toutefois place à une compression ultérieure.
La taille des preuves STARK, quant à elle, ne croît pas avec la taille du calcul, ce qui la rend plus adaptée à la vérification de calculs très volumineux. Pour améliorer davantage l’expérience développeur, RiscZero a lancé le réseau Bonsai, un réseau de calcul distribué dont les preuves sont vérifiées par RiscZero. Voici un schéma simplifié du fonctionnement du réseau Bonsai de RiscZero.
La beauté du réseau Bonsai réside dans le fait que l’initialisation, la vérification et la sortie du calcul peuvent toutes être réalisées on-chain. Tout cela semble utopique, mais les preuves STARK posent aussi un problème : leur coût de vérification est trop élevé.
Les preuves Nova semblent parfaitement adaptées aux calculs répétitifs (grâce à leur schéma de pliage économique) et aux petits calculs, ce qui pourrait faire de Lurk une excellente solution pour la vérification d’inférences ML.
Qui sont les gagnants ?
Certains systèmes zk-SNARK nécessitent, lors de la phase d’installation initiale, un paramètre dit « de configuration fiable », générant un ensemble de paramètres initiaux. L’hypothèse de confiance ici est que cette configuration a été effectuée honnêtement, sans comportement malveillant ou manipulation. En cas d’attaque, cela pourrait permettre la création de preuves invalides.
Les preuves STARK reposent sur la sécurité du test de faible degré, utilisé pour vérifier la propriété de faible degré des polynômes. Elles supposent aussi que les fonctions de hachage se comportent comme des oracles aléatoires.
Une mise en œuvre correcte des deux systèmes constitue également une hypothèse de sécurité.
Les réseaux SMPC reposent sur les points suivants :
-
Les participants SMPC peuvent inclure des acteurs « honnêtes mais curieux », qui chercheraient, par communication avec d’autres nœuds, à accéder à des informations sous-jacentes.
-
La sécurité du réseau SMPC suppose que les participants exécutent correctement le protocole, sans introduire sciemment d’erreurs ou comportements malveillants.
-
Certains protocoles SMPC peuvent nécessiter une phase de configuration fiable pour générer des paramètres cryptographiques ou valeurs initiales. L’hypothèse ici est que cette configuration est effectuée de manière honnête.
-
Contrairement au SMPC classique, les hypothèses de sécurité restent identiques, mais grâce à l’OTM (Off-The-Grid Multi-party Computation), il n’y a plus de participants « honnêtes mais curieux ».
L’OTM est un protocole de calcul multipartite conçu pour protéger la vie privée des participants. Il empêche les participants de divulguer leurs données d’entrée durant le calcul, assurant ainsi la confidentialité. Par conséquent, les participants « honnêtes mais curieux » ne peuvent pas exister, car ils ne peuvent pas communiquer pour tenter d’accéder à l’information cachée.
Y a-t-il un vainqueur clair ? Nous ne le savons pas. Chaque méthode a ses propres avantages. Bien que le NMC semble être une évolution naturelle du SMPC, le réseau n’est pas encore lancé ni testé en conditions réelles.
Le bénéfice du calcul vérifiable ZK est qu’il est sécurisé et protège la vie privée, mais il ne dispose pas nativement d’un mécanisme de partage secret. L’asymétrie entre la génération et la vérification des preuves en fait un modèle idéal pour l’externalisation vérifiable du calcul. Toutefois, si le système repose uniquement sur le calcul ZK vérifiable, l’ordinateur (ou nœud unique) doit être extrêmement puissant pour exécuter de gros calculs. Pour permettre un partage et un équilibrage de charge tout en protégeant la vie privée, un mécanisme de partage secret est indispensable. Dans ce cas, des systèmes comme SMPC ou NMC peuvent être combinés avec des générateurs ZK comme Lurk ou RiscZero, afin de créer une infrastructure puissante de calcul externalisé, distribué et vérifiable.
Les réseaux MPC/SMPC actuels sont centralisés, ce qui rend cette question particulièrement importante. Aujourd’hui, le plus grand fournisseur MPC est Sharemind, et l’ajout d’une couche de vérification ZK pourrait s’avérer utile. Le modèle économique des réseaux MPC décentralisés n’a pas encore fait ses preuves. Théoriquement, le modèle NMC est une amélioration du système MPC, mais nous n’avons pas encore vu de succès concret.
Dans la course aux schémas de preuve ZK, il est peu probable qu’il y ait un seul gagnant absolu. Chaque méthode de preuve est optimisée pour un type spécifique de calcul, et aucun modèle universel ne convient à tous. Les tâches de calcul sont variées, et les choix dépendront des compromis faits par les développeurs sur chaque système de preuve. L’auteur pense que les systèmes basés sur STARK, ceux basés sur SNARK, ainsi que leurs futurs perfectionnements, ont tous une place légitime dans l’avenir du ZK.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
IOSG Ventures
