L'un des moyens peu discutés, mais néanmoins très importants, dont Ethereum assure la sécurité et la décentralisation est sa philosophie multi-clients. Ethereum n'a intentionnellement aucun « client de référence » que tout le monde exécute par défaut : il existe plutôt une spécification gérée de manière collaborative (écrite aujourd'hui en Python, très lisible par l'homme mais très lent) et plusieurs équipes mettent en œuvre la spécification (également appelée « clients »), c'est ce que les utilisateurs exécutent réellement.

Chaque nœud Ethereum gère un client de consensus et un client d'exécution. À ce jour, aucun client de consensus ou d'exécution ne représente plus des deux tiers du réseau. Si un client qui détient moins d'un tiers des parts de sa catégorie rencontre un bogue, le réseau continuera à fonctionner normalement. Si un client qui détient entre 1/3 et 2/3 des parts dans sa catégorie (Prysm, Lighthouse ou Geth, par exemple) rencontre un bogue, la chaîne continuera à ajouter des blocs, mais arrêtera de les finaliser, laissant le temps aux développeurs d'intervenir.

L'une des principales transitions à venir, peu discutée mais néanmoins très importante, dans la manière dont la chaîne Ethereum sera validée est la montée en puissance des zK-EVM. LesSNARKs prouvant l'exécution de l'EVM sont en cours de développement depuis des années déjà, et cette technologie est activement utilisée par des protocoles de couche 2 appelés ZK rollups. Certains de ces cumuls ZK sont actifs sur le réseau principal aujourd'hui, et d'autres seront bientôt disponibles. Mais à long terme, les zK-EVM ne seront pas uniquement destinés aux cumuls ; nous voulons également les utiliser pour vérifier l'exécution en couche 1 (voir aussi : the Verge).

Une fois cela fait, les zk-EVM deviendront de facto un troisième type de client Ethereum, tout aussi important pour la sécurité du réseau que le sont les clients d'exécution et les clients de consensus aujourd'hui. Et cela soulève naturellement une question : comment les zK-EVM interagiront-ils avec la philosophie multi-clients ? L'une des choses les plus difficiles est déjà terminée : nous avons déjà plusieurs implémentations de ZK-EVM qui sont activement développées. Mais d'autres difficultés demeurent : comment créer un écosystème « multi-clients » permettant à ZK de prouver l'exactitude des blocs Ethereum ? Cette question soulève des défis techniques intéressants et, bien entendu, la question imminente de savoir si les compromis en valent la peine.

Qu'est-ce qui a motivé à l'origine la philosophie multi-clients d'Ethereum ?

La philosophie multi-clients d'Ethereum est une sorte de décentralisation, et à l'instar de la décentralisation < a href= " https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274 " > en général, on peut se concentrer soit sur les avantages techniques de la décentralisation architecturale, soit sur les avantages sociaux de la décentralisation politique. En fin de compte, la philosophie multi-clients a été motivée par les deux et sert les deux.

Les arguments en faveur de la décentralisation technique

Le principal avantage de la décentralisation technique est simple : elle réduit le risque qu'un bogue dans un logiciel entraîne une panne catastrophique de l'ensemble du réseau. Une situation historique qui illustre ce risque est le bug de débordement de Bitcoin en 2010. À l'époque, le code client Bitcoin ne vérifiait pas que la somme des résultats d'une transaction ne dépassait pas (arrondissez à zéro en additionnant jusqu'à un entier supérieur à 2⁶⁴−1), et quelqu'un a donc effectué une transaction qui a fait exactement cela, en se donnant des milliards de bitcoins. Le bogue a été découvert en quelques heures, et un correctif a été rapidement adopté et rapidement déployé sur le réseau, mais s'il y avait eu un écosystème mature à l'époque, ces pièces auraient été acceptées par les bourses, les ponts et autres structures, et les attaquants auraient pu s'en tirer avec beaucoup d'argent. S'il y avait eu cinq clients Bitcoin différents, il aurait été très peu probable qu'ils aient tous le même bogue. Il y aurait donc eu une scission immédiate, et le côté bogué aurait probablement perdu.

Il y a un compromis à faire en utilisant l'approche multi-clients pour minimiser le risque de bugs catastrophiques : au lieu de cela, vous obtenez des bogues d'échec consensuels. En d'autres termes, si vous avez deux clients, ils risquent d'avoir des interprétations légèrement différentes de certaines règles protocolaires. Bien que les deux interprétations soient raisonnables et n'autorisent pas le vol d'argent, un désaccord provoquerait une division de la chaîne en deux. Une grave scission de ce type s'est produite une fois dans l'histoire d'Ethereum (il y a eu d'autres divisions beaucoup plus petites où de très petites parties du réseau utilisant d'anciennes versions du code ont été bifurquées). Les défenseurs de l'approche client unique invoquent l'échec du consensus pour expliquer l'absence de plusieurs implémentations : s'il n'y a qu'un seul client, celui-ci ne sera pas en désaccord avec lui-même. Leur modèle de la façon dont le nombre de clients se traduit en risque peut ressembler à ceci :

Bien entendu, je ne suis pas d'accord avec cette analyse. Le cœur de mon désaccord est que (i) les bugs catastrophiques de style 2010 sont également importants, et (ii) vous n'avez jamais qu'un seul client. Ce dernier point est mis en évidence par le fork du Bitcoin en 2013: une rupture de chaîne s'est produite à la suite d'un désaccord entre deux versions différentes du client Bitcoin, dont l'une a révélé une limite accidentelle et non documentée au nombre d'objets pouvant être modifiés dans un seul bloc. Ainsi, un client en théorie est souvent deux clients en cabinet, et cinq clients en théorie, cela peut faire six ou sept clients en cabinet. Nous devrions donc simplement franchir le pas et nous placer du bon côté de la courbe de risque, et avoir au moins quelques clients différents.

Les arguments en faveur de la décentralisation politique

Les développeurs de clients Monopoly ont un pouvoir politique important. Si un développeur client propose une modification et que les utilisateurs ne sont pas d'accord, il peut théoriquement refuser de télécharger la version mise à jour ou créer un fork sans celle-ci, mais dans la pratique, c'est souvent difficile pour les utilisateurs de le faire. Et si un changement de protocole désagréable était associé à une mise à jour de sécurité nécessaire ? Et si l'équipe principale menace de démissionner si elle n'obtient pas ce qu'elle veut ? Ou, plus calmement, et si l'équipe cliente monopolistique finissait par être la seule à posséder la meilleure expertise en matière de protocoles, laissant le reste de l'écosystème mal placé pour évaluer les arguments techniques avancés par l'équipe client, laissant à l'équipe client une grande marge de manœuvre pour défendre ses propres objectifs et valeurs, ce qui pourrait ne pas correspondre à ceux de l'ensemble de la communauté ?

Les inquiétudes suscitées par la politique des protocoles, en particulier dans le contexte de la guerre OP_RETURN du Bitcoin en 2013-2014, au cours de laquelle certains participants se sont montrés ouvertement favorables à la discrimination à l'égard de certains usages de la chaîne, ont largement contribué à l'adoption précoce par Ethereum d'une philosophie multi-clients, visant à empêcher un petit groupe de prendre ce type de décisions. Les préoccupations spécifiques à l'écosystème Ethereum, à savoir éviter la concentration du pouvoir au sein de la Fondation Ethereum elle-même, ont contribué à renforcer cette orientation. En 2018, il a été décidé de demander intentionnellement à la Fondation de ne pas implémenter le protocole Ethereum PoS (c'est-à-dire ce que l'on appelle aujourd'hui un « client consensuel »), laissant cette tâche entièrement à des équipes extérieures.

Comment les ZK-EVM occuperont-ils la couche 1 à l'avenir ?

Aujourd'hui, les zK-EVM sont utilisés dans le cadre de cumuls. Cela augmente la mise à l'échelle en ne permettant que quelques exécutions coûteuses d'EVM hors chaîne, les autres vérifiant simplement les SNARKs publiés sur la chaîne qui prouvent que l'exécution de l'EVM a été correctement calculée. Cela permet également de ne pas inclure certaines données (en particulier les signatures) dans la chaîne, ce qui permet d'économiser sur les frais de gaz. Cela nous apporte de nombreux avantages en termes d'évolutivité, et la combinaison d'un calcul évolutif avec zK-EVM et de données évolutives avec < a href= " https://hackmd.io/@vbuterin/sharding_proposal #ELI5 -data-availability-sampling " > data availability sampling pourrait nous permettre d'évoluer très loin.

Cependant, le réseau Ethereum est aujourd'hui confronté à un autre problème, qu'aucune mise à l'échelle de la couche 2 ne peut résoudre à elle seule : la couche 1 est difficile à vérifier, au point que peu d'utilisateurs gèrent leur propre nœud. Au lieu de cela, la plupart des utilisateurs font simplement confiance à des fournisseurs tiers. Les clients légers tels que Helios et Succinct prennent des mesures pour résoudre le problème, mais un client léger est loin d'être un nœud de vérification complet : un client léger vérifie simplement les signatures d'un sous-ensemble aléatoire de validateurs appelé comité de synchronisation, et ne vérifie pas si la chaîne respecte réellement les règles du protocole. Pour que les utilisateurs puissent réellement vérifier que la chaîne respecte les règles, il faudrait faire quelque chose de différent.

Option 1 : restreindre la couche 1, forcer presque toutes les activités à passer à la couche 2

Au fil du temps, nous pourrions réduire l'objectif de gaz par bloc de la couche 1 de 15 millions à 1 million, soit assez pour qu'un bloc contienne un seul SNARK et quelques opérations de dépôt et de retrait, mais pas grand-chose d'autre, et obliger ainsi presque toutes les activités des utilisateurs à passer aux protocoles de couche 2. Une telle conception pourrait tout de même prendre en charge de nombreux cumuls dans chaque bloc : nous pourrions utiliser des protocoles d'agrégation hors chaîne gérés par des créateurs personnalisés pour rassembler les SNARK issus de plusieurs protocoles de couche 2 et les combiner en un seul SNARK. Dans un tel monde, la seule fonction de la couche 1 serait de servir de centre d'échange pour les protocoles de couche 2, de vérifier leurs preuves et de faciliter de temps en temps des transferts de fonds importants entre eux.

Cette approche peut fonctionner, mais elle présente plusieurs points faibles importants :

• C'est de facto rétroincompatible, dans le sens où de nombreuses applications basées sur la L1 existantes deviennent économiquement non viables. Les fonds des utilisateurs pouvant atteindre des centaines ou des milliers de dollars peuvent être bloqués car les frais deviennent si élevés qu'ils dépassent le coût du vidage de ces comptes. Cela pourrait être résolu en laissant les utilisateurs signer des messages pour participer à une migration de masse intégrée au protocole vers la L2 de leur choix (voir quelques premières idées d'implémentation ici), mais cela complique la transition, et pour la rendre vraiment suffisamment économique, il faudrait de toute façon une sorte de SNARK au niveau de la couche 1. En général, je préfère rompre la rétrocompatibilité quand il s'agit de < a href= " https://hackmd.io/@vbuterin/selfdestruct " >, des choses comme l'opcode SELFDESTRUCT, mais dans ce cas, le compromis semble bien moins favorable.
• Cela ne rendra peut-être pas la vérification assez bon marché. Idéalement, le protocole Ethereum devrait être facile à vérifier, non seulement sur les ordinateurs portables, mais aussi sur les téléphones, les extensions de navigateur et même sur d'autres chaînes. Synchroniser la chaîne pour la première fois, ou après une longue période hors ligne, devrait également être facile. Un nœud d'ordinateur portable peut vérifier 1 million de gaz en 20 ms environ, mais cela implique 54 secondes pour synchroniser après une journée hors ligne (en supposant que < a href= " https://notes.ethereum.org/@vbuterin/single_slot_finality " > single la finalité des machines à sous augmente la durée des créneaux à 32 secondes), et pour les téléphones ou les extensions de navigateur, cela peut prendre quelques centaines de millisecondes par bloc et cela peut tout de même entraîner une consommation de batterie non négligeable. Ces chiffres sont gérables, mais ils ne sont pas idéaux.
• Même dans un écosystème L2 d'abord, il y a des avantages à ce que la L1 soit au moins assez abordable. Les validiums peuvent bénéficier d'un modèle de sécurité renforcé si les utilisateurs peuvent retirer leurs fonds s'ils remarquent que de nouvelles données nationales ne sont plus disponibles. L'arbitrage devient plus efficace, en particulier pour les petits jetons, si la taille minimale d'un transfert direct inter-L2 économiquement viable est plus petite.

Il semble donc plus raisonnable d'essayer de trouver un moyen d'utiliser zk-SNARKS pour vérifier la couche 1 elle-même.

Option 2 : vérifier la couche 1 par SNARK

Un ZK-EVM de type 1 (totalement équivalent à Ethereum) peut être utilisé pour vérifier l'exécution par EVM d'un bloc Ethereum (couche 1). Nous pourrions écrire davantage de code SNARK pour vérifier également le côté consensus d'un bloc. Ce serait un problème d'ingénierie difficile : aujourd'hui, les zK-EVM mettent des minutes à des heures pour vérifier les blocs d'Ethereum, et pour générer des preuves en temps réel, il faudrait (i) améliorer Ethereum lui-même afin de supprimer les composants hostiles au SNARK, (ii) soit des gains d'efficacité importants grâce à du matériel spécialisé, soit (iii) des améliorations architecturales avec beaucoup plus de parallélisation. Cependant, il n'y a aucune raison technologique fondamentale pour laquelle cela ne peut pas être fait. Je pense donc que ce sera fait, même si cela prend de nombreuses années.

C'est là que nous voyons l'intersection avec le paradigme multi-clients : si nous utilisons des zK-EVM pour vérifier la couche 1, quel ZK-EVM utilisons-nous ?

Trois options s'offrent à moi :

1. ZK-EVM unique : abandonnez le paradigme multi-clients et choisissez un seul ZK-EVM que nous utiliserons pour vérifier les blocs.
2. Plusieurs ZK-EVM fermés : convenez et inscrivez par consensus un ensemble spécifique de plusieurs ZK-EVM, et appliquez une règle de protocole de couche consensuelle selon laquelle un bloc nécessite des preuves provenant de plus de la moitié des ZK-EVM de cet ensemble pour être considéré comme valide.
3. Ouvrez plusieurs ZK-EVM : différents clients ont des implémentations ZK-EVM différentes, et chaque client attend une preuve compatible avec sa propre implémentation avant de considérer un bloc comme valide.

Pour moi, (3) semble idéal, du moins jusqu'à ce que notre technologie s'améliore au point que nous puissions prouver officiellement que toutes les implémentations de ZK-EVM sont équivalentes les unes aux autres. À ce moment-là, nous pourrons simplement choisir celle qui est la plus efficace. (1) sacrifierait les avantages du paradigme multi-clients, et (2) supprimerait la possibilité de développer de nouveaux clients et conduirait à un écosystème plus centralisé. (3) présente des défis, mais ces défis semblent moindres que ceux des deux autres options, du moins pour l'instant.

Implémenter (3) ne serait pas trop difficile : il peut y avoir un sous-réseau p2p pour chaque type de preuve, et un client qui utilise un type de preuve écouterait le sous-réseau correspondant et attendrait de recevoir une preuve reconnue comme valide par son vérificateur.

Les deux principaux défis de (3) sont probablement les suivants :

• Le défi de la latence : un attaquant malveillant peut publier un bloc en retard, accompagné d'une preuve valide pour un client. En réalité, cela prendrait beaucoup de temps (ne serait-ce que 15 secondes) pour générer des preuves valables pour les autres clients. Ce délai serait suffisant pour créer un fork temporaire et perturber la chaîne pendant quelques machines à sous.
• Inefficacité des données : l'un des avantages de zk-SNARKS est que les données qui ne concernent que la vérification (parfois appelées « données témoins ») peuvent être supprimées d'un bloc. Par exemple, une fois que vous avez vérifié une signature, vous n'avez pas besoin de la conserver dans un bloc, vous pouvez simplement stocker un seul bit indiquant que la signature est valide, ainsi qu'une seule preuve dans le bloc confirmant l'existence de toutes les signatures valides. Cependant, si nous voulons qu'il soit possible de générer des preuves de plusieurs types pour un bloc, les signatures originales devront être publiées.

Le problème de latence pourrait être résolu en faisant preuve de prudence lors de la conception du protocole de finalité à emplacement unique. Les protocoles de finalité à emplacement unique nécessiteront probablement plus de deux cycles de consensus par créneau. Il se peut donc que le premier tour inclue le bloc, et que les nœuds vérifient les preuves uniquement avant de signer au troisième (ou dernier) tour. Cela garantit qu'un laps de temps important est toujours disponible entre la date limite de publication d'un bloc et la date à laquelle les épreuves devraient être disponibles.

Le problème de l'efficacité des données devrait être résolu en mettant en place un protocole distinct pour l'agrégation des données liées à la vérification. Pour les signatures, nous pourrions utiliser l'agrégation BLS, que l'ERC-4337 prend déjà en charge. Les zk-SNARKS, utilisés pour des raisons de confidentialité, constituent une autre catégorie importante de données liées à la vérification. Heureusement, ils ont souvent leurs propres protocoles d'agrégation.

Il convient également de mentionner que la vérification SNARK de la couche 1 présente un avantage important : le fait que l'exécution des EVM en chaîne n'ait plus besoin d'être vérifiée par tous les nœuds permet d'augmenter considérablement le nombre d'exécutions d'EVM en cours. Cela peut se faire soit en augmentant considérablement la limite de gaz de la couche 1, soit en introduisant des rollups intégrés, soit les deux.

Conclusions

Faire fonctionner correctement un écosystème ZK-EVM multi-clients ouvert demandera beaucoup de travail. Mais la très bonne nouvelle, c'est qu'une grande partie de ce travail est en cours ou aura lieu de toute façon :

• Nous avons déjà plusieurs implémentations robustes de ZK-EVM. Ces implémentations ne sont pas encore de type 1 (totalement équivalentes à Ethereum), mais nombre d'entre elles évoluent activement dans cette direction.
• Le travail sur des clients légers tels que Helios et Succinct pourrait éventuellement se transformer en une vérification SNARK plus complète du consensus PoS de la chaîne Ethereum.
• Les clients vont probablement commencer à expérimenter les zk-EVM pour prouver eux-mêmes l'exécution des blocs d'Ethereum, en particulier une fois que nous avons des clients apatrides et qu'il n'est pas techniquement nécessaire de réexécuter directement chaque bloc pour maintenir l'état. Nous allons probablement avoir une transition lente et progressive entre les clients qui vérifient les blocs Ethereum en les réexécutant et la plupart des clients vérifiant les blocs Ethereum en vérifiant les preuves SNARK.
• Les écosystèmes ERC-4337 et PBS devraient bientôt commencer à fonctionner avec des technologies d'agrégation telles que le BLS et l'agrégation de preuves, afin de réduire les coûts de gaz. En ce qui concerne l'agrégation BLS, le travail a déjà commencé.

Avec ces technologies en place, l'avenir s'annonce très prometteur. Les blocs d'Ethereum seraient plus petits qu'aujourd'hui, n'importe qui pourrait exécuter un nœud de vérification complet sur son ordinateur portable, son téléphone ou dans une extension de navigateur, et tout cela tout en préservant les avantages de la philosophie multi-clients d'Ethereum.

À plus long terme, bien entendu, tout peut arriver. Peut-être que l'IA va renforcer la vérification formelle au point de pouvoir facilement prouver l'équivalence des implémentations de ZK-EVM et identifier tous les bogues qui les différencient. Il pourrait même être pratique de commencer à travailler sur un tel projet dès maintenant. Si une telle approche officielle basée sur la vérification est couronnée de succès, différents mécanismes devront être mis en place pour garantir la poursuite de la décentralisation politique du protocole ; peut-être qu'à ce moment-là, le protocole serait considéré comme « complet » et les normes d'immuabilité seraient renforcées. Mais même si c'est l'avenir à long terme, le monde ouvert et multi-clients de ZK-EVM semble être un tremplin naturel qui est susceptible de se produire de toute façon.

À court terme, le chemin sera encore long. Les ZK-EVM sont là, mais pour devenir vraiment viables en couche 1, il faudrait qu'ils passent au type 1, et qu'ils puissent être prouvés assez rapidement pour que cela puisse se produire en temps réel. Avec suffisamment de parallélisation, c'est faisable, mais il faudra encore beaucoup de travail pour y parvenir. Les changements de consensus, tels que l'augmentation du coût du gaz de KECCAK, SHA256 et d'autres précompilations de fonctions de hachage, occuperont également une place importante dans le tableau. Cela dit, les premières étapes de la transition pourraient avoir lieu plus tôt que prévu : une fois que nous serons passés aux arbres Verkle et aux clients apatrides, les clients pourraient commencer à utiliser zK-EVM progressivement, et la transition vers un monde « ouvert multi-ZK-EVM » pourrait commencer à se faire d'elle-même.

Avertissement：

1. Cet article est reproduit depuis [Vitalik]. Tous les droits d'auteur appartiennent à l'auteur original[Vitalik]. En cas d'objection à cette réimpression, contactez l'équipe de Gate Learn, elle s'en occupera rapidement.
2. Avertissement en matière de responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent en aucun cas un conseil d'investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.