Pourquoi la prochaine étape d’Ethereum est une connaissance nulle

Au cours de la dernière année, des étapes majeures ont été franchies le long de la feuille de route d’Ethereum qui ont amélioré le réseau. EIP-4844 (alias Dencun) a introduit les blobs et le proto-danksharding, rendant le stockage de données beaucoup moins cher pour les couches 2 et entraînant des frais de transaction bien inférieurs.

Pendant ce temps, les couches 2 (pour la plupart de type optimiste) sont devenues plus intégrées et largement utilisées dans les applications, permettant d’effectuer des transactions pour moins d’un centime et améliorant l’infrastructure fondamentale d’Ethereum.

Cependant, comme le savent tous ceux qui ont prêté attention aux frais de gaz, il y a encore trop de congestion sur Ethereum, et à mesure que l’utilisation réelle des blockchains se développe, de plus en plus de dApps seront en compétition pour l’espace de bloc et le calcul.

Il n’est pas nécessaire d’être ingénieur ou cryptographe pour savoir que cela n’est pas durable. Nous avons vu ce qui se passe lorsqu’Ethereum devient trop encombré. Dans certains moments particulièrement intenses, les utilisateurs ont payé plus de 2 ETH juste pour terminer une transaction, et certaines de ces transactions ont toujours échoué alors que les utilisateurs se sont efforcés de les prioriser.

Dans un monde parfait, nous déplacerions une grande partie de ces calculs hors chaîne, tout en étant en mesure de publier une preuve succincte et vérifiable garantissant que les données sont correctes et au bon endroit.

Les preuves sans connaissance rendent cela possible, mais il reste difficile pour les blockchains de vérifier les transactions avec autant de possibilités potentielles dans l’EVM, et il peut rapidement devenir coûteux d’emprunter cette voie. Les Zk-rollups doivent payer pour du matériel spécialisé qui crée une preuve ZK via un prouveur, et qui doit ensuite généralement être converti en un type de preuve qu’Ethereum peut comprendre.

En bref, les cumuls optimistes sont relativement faciles et abordables à vérifier, tandis que les cumuls zk sont difficiles et coûteux. Pour les petites et même moyennes entreprises qui souhaitent exercer une partie de leurs activités en chaîne et les garder confidentielles, les zk-rollups sont la voie à suivre, mais la vérification des preuves peut être une dépense prohibitive.

Les écosystèmes de rollup ont leurs propres intérêts

Jusqu’à présent, les L2 de marque n’étaient pas intéressés par une solution modulaire de vérification des preuves comme zkVerify, qui peut réduire les coûts de vérification de 90 % ou plus. Ils pourraient l’adopter plus tard, mais ce n’est pas leur objectif pour le moment. Généralement, les grands écosystèmes L2 croient en la vérification de toutes ces preuves ZK sur la même chaîne et en amortissant ces coûts entre les utilisateurs.

Cependant, nous avons trouvé une opportunité auprès des fournisseurs de rollup-as-a-service (RaaS), car ils croient en une approche modulaire des blockchains et ont tendance à servir des projets de petite et moyenne taille qui ne peuvent pas se permettre de payer ces coûts de vérification. Pour eux, l’idée d’envoyer des preuves à une chaîne autonome, puis de renvoyer la vérification des preuves à Ethereum a beaucoup de sens. Tout comme pour la disponibilité modulaire des données, nous voyons désormais les fournisseurs RaaS adopter la vérification modulaire à bras ouverts.

Les grands L2 ont deux arguments principaux contre cette approche : premièrement, ils estiment que le fait de déplacer la vérification des preuves vers un niveau différent diminue la sécurité du L2. En réalité, certains de ces L2 vérifient déjà leurs preuves hors chaîne. Ils n’en font tout simplement pas la publicité.

Leur autre argument est qu’ils préféreraient regrouper les preuves, en regroupant un grand nombre de preuves et en créant essentiellement une « preuve de preuves ». Ce faisant, les grands L2 sont capables de répartir les coûts sur un nombre beaucoup plus important de transactions. Cependant, ils ne semblent pas tellement préoccupés par le fait qu’avec cette approche, cela puisse prendre quelques heures pour regrouper des centaines de preuves, pour un coût potentiellement plus élevé.

L’agrégation est logique pour de nombreux cas d’utilisation, mais pas nécessairement pour une application dans laquelle vous souhaitez faire quelque chose rapidement et le faire vérifier dans le même laps de temps.

En fin de compte, vous devez toujours faire confiance à la L2 sur laquelle vous évoluez.

D’une certaine manière, l’EVM est bloqué en 2017

Alors que notre équipe continuait à creuser dans l’espace ZK et la relation d’Ethereum avec lui, nous avons découvert qu’Ethereum avait en fait une certaine compatibilité avec les courbes elliptiques à connaissance nulle utilisant une précompilation, ce qui rend essentiellement plus efficace la gestion des calculs impliqués dans la vérification d’une preuve. Mais le réseau ne prend actuellement en charge que trois opérations mathématiques sur une seule courbe.

Qu’est-ce que cela signifie pour les utilisateurs ? Étant donné que certains zk-SNARK ne peuvent pas être vérifiés, cela nécessite que les preuves soient présentées sous une forme plus conviviale (en utilisant la preuve bn128), ce qui entraîne moins d’efficacité, plus de marge d’erreur et des coûts potentiellement plus élevés. Idéalement, les développeurs devraient pouvoir choisir le zk-SNARK qui correspond le mieux à leur application, et ne pas pouvoir le faire signifie qu’ils doivent faire des compromis sur la qualité.

Techniquement, il est possible pour Ethereum d’adopter des précompilations plus avancées au fil du temps, mais leur mise en œuvre peut prendre des années. La dernière précompilation a été implémentée en 2017, et il n’y en a eu aucune depuis.

Pourquoi donc? Un manque de demande ? N’est-il réellement pas possible de les implémenter sur Ethereum ? Et même si la communauté en est capable, serait-il toujours inefficace de calculer avec ces nouvelles précompilations sur l’EVM ?

Ce n’est pas clair. Mais ce qui est clair, c’est que l’EVM doit être remanié, et la vérification des preuves ZK en chaîne est encore trop coûteuse pour le cas d’utilisation moyen. Après le matériel, c’est la plus grosse dépense lors de l’utilisation d’un zk-rollup.

Chez Horizen Labs, nous abordons ce problème de deux manières : en proposant une vérification de preuve modulaire sous la forme de zkVerify et en créant une chaîne entièrement compatible EVM avec prise en charge des dernières précompilations sans connaissance.

Par exemple, Horizen 2.0 est construit sur Substrate, ce qui permet des mises à niveau sans fork qui sont automatiquement appliquées juste après un vote de la communauté. Aucun travail ne doit être effectué côté nœud et aucun hard fork n’est requis.

Certaines équipes préféreront rester au sein d’un écosystème dédié comme Horizen 2.0, avec sa propre communauté soudée et ses propres effets de réseau. D’autres choisiront d’emprunter la voie RaaS pour créer leur propre rollup personnalisé, et ils pourront également profiter des économies de coûts liées à la vérification des preuves hors chaîne.

Il existe plusieurs façons de faire évoluer l’EVM avec ZK, mais nous pensons que cela doit se produire avant la prochaine vague d’adoption.