Brian Pak est PDG et co-fondateur de ChainLight, une société de sécurité blockchain spécialisée dans les audits de contrats intelligents et la surveillance en chaîne.

Les mots zéro connaissance, autrefois relégués aux articles universitaires et aux forums de cryptographie, sont devenus monnaie courante.

La technologie ZK permet à une partie, comme un protocole blockchain, de prouver à une autre partie que quelque chose est vrai, comme l'âge d'une personne, tout en gardant ces informations totalement confidentielles.

La cryptographie ZK réussit à faire évoluer le réseau de contrats intelligents Ethereum. Plus d’une douzaine de réseaux basés sur ZK, communément appelés ZK rollups, fonctionnent sur Ethereum, avec un total de dépôts d’une valeur de 4 milliards de dollars.

Mais malgré tout ce battage médiatique, il y a un gros problème. Le manque de connaissances sur ZK est une bombe à retardement.

La plupart des développeurs de crypto en savent encore très peu sur ce sujet complexe.

Et à mesure que de plus en plus de développeurs commencent à expérimenter la technologie ZK, cela crée des risques de sécurité majeurs, et empêche même la technologie d’atteindre son véritable potentiel.

Dans le même temps, la technologie ZK promet de révolutionner l’industrie de la cryptographie, il est donc impératif de mettre les développeurs et la communauté plus large des utilisateurs au courant.

Les développeurs de ZK sont « dépassés »

En 2022, le co-fondateur d'Ethereum, Vitalik Buterin, a souligné les risques de sécurité des cumuls ZK, tels que des bogues dans le code de contrainte du circuit.

Ces codes sont essentiels dans les cumuls ZK car ils définissent et appliquent des règles pour les preuves cryptographiques garantissant la validité des transactions.

Les bogues dans ces codes peuvent entraîner de graves vulnérabilités de sécurité, telles que des preuves incorrectes ou un accès non autorisé aux fonds.

Depuis l’avertissement de Buterin, les développeurs ont identifié plusieurs autres vulnérabilités dans les projets utilisant la technologie ZK.

En novembre, ChainLight a découvert un bug dans les circuits ZK de ZK Sync Era qui aurait pu permettre à un pirate informatique de voler 1,9 milliard de dollars.

Également en 2018, un cryptographe de Zcash a découvert une vulnérabilité dans les preuves sans connaissance qui sous-tendent le protocole. S'il n'avait pas été corrigé, le bug aurait pu permettre à un attaquant de créer de faux jetons Zcash sans être détecté.

De telles vulnérabilités constituent un triste réquisitoire contre une nouvelle forme de technologie qui n’est clairement pas comprise par un nombre suffisant de personnes.

De nombreux développeurs qui écrivent le code et les professionnels de la sécurité qui doivent en approuver la sécurité sont tout simplement dépassés.

Et ce n’est pas surprenant : tout le monde vous dira qu’un niveau de doctorat en mathématiques est nécessaire pour comprendre les aspects de sécurité de la technologie ZK.

Cela signifie que le nombre de personnes qualifiées pour auditer le code ZK est limité, tout comme les ressources nécessaires pour les former.

Et le manque d’experts pour auditer correctement le code ZK n’est pas le seul problème.

Les cumuls ZK, tels que zkSync Era et StarkNet, sont développés en interne et, par conséquent, les processus d'évaluation par les pairs ne sont pas aussi approfondis que les normes observées dans le monde universitaire.

Je resterai sceptique quant à la sécurité de la technologie ZK jusqu'à ce que le processus d'examen par les pairs soit plus standardisé.

ZK n’atteint pas son potentiel

Le manque de compréhension de la technologie ZK l’empêche également d’exploiter tout son potentiel.

Cela est dû à un manque de confiance dans la technologie qui conduit les constructeurs à choisir des frameworks plus familiers.

Par exemple, l’un des principaux avantages vantés des cumuls ZK est la finalité instantanée.

Cela signifie que dès que la preuve d’un blocage est vérifiée sur le réseau principal Ethereum, les résultats sont définitifs. Cela permet notamment des retraits d’actifs instantanés et améliore également la sécurité.

Les rollups optimistes, le principal rival des rollups ZK, nécessitent une période d'attente de sept jours pour retirer les actifs.

Il existe un consensus croissant selon lequel les cumuls ZK constituent la meilleure solution pour faire évoluer Ethereum au-delà des cumuls optimistes.

Certains vont jusqu’à les décrire comme le « Saint Graal » des solutions de mise à l’échelle.

Le co-fondateur d'Immutable X, Robbie Ferguson, a décrit les cumuls ZK comme « de loin le moyen le plus simple de faire évoluer les transactions à haut débit ».

Mais, en réalité, la plupart des développeurs n’utilisent toujours pas la technologie à son véritable potentiel, car ils ne sont tout simplement pas à l’aise avec l’utilisation de certaines de ses fonctionnalités uniques en raison de sa complexité.

Par exemple, aucun des cumuls ZK existants n’a réellement la finalité instantanée annoncée.

Le codage est si technique que les développeurs pourraient avoir peur de commettre une erreur, ce qui les amènerait à choisir de ne pas implémenter la finalité instantanée.

Au lieu de cela, les protocoles ont ce qu'on appelle un délai d'exécution, dans lequel il existe une fenêtre d'environ un jour pour détecter un exploit et annuler les modifications avant qu'elles ne soient finalisées.

Avec cela, la sécurité des rollups ZK s’accompagne d’un compromis majeur et renonce à l’un de ses avantages les plus importants.

Seule une meilleure compréhension de la technologie ZK permettra aux constructeurs de maximiser son potentiel sans compromettre la sécurité.

La sécurité dès la conception

Dans l’ensemble du Web3 – et pas seulement dans la sphère ZK – les projets ne prennent pas les audits suffisamment au sérieux.

De nombreux projets considèrent les audits simplement comme des cachets d'approbation pour se donner une apparence réputée, plutôt que comme des exercices rigoureux de sécurité qu'ils devraient être.

Il existe plusieurs cas où des bugs connus se sont glissés dans les nouveaux protocoles DeFi, coûtant des millions aux investisseurs.

Par exemple, plusieurs protocoles qui ont dérivé le code du protocole de prêt Compound v2, tels que Hundred Finance et Onyx Protocol, l'ont fait aveuglément et n'ont pas pris en compte les vecteurs d'attaque connus dans le code.

Au lieu de cela, les développeurs devraient s’efforcer de créer des protocoles sécurisés dès leur conception, ce qui signifie qu’ils sont construits de manière à protéger avant tout contre les attaques.

La construction par conception commence par se tenir au courant des menaces qui pèsent sur l'écosystème.

Si un projet ne dispose pas des ressources nécessaires pour effectuer un audit approfondi, il doit néanmoins suivre les piratages qui surviennent sur d’autres projets afin qu’ils ne soient pas eux-mêmes victimes.

Même si le fait de ne pas créer de protocoles sécurisés dès leur conception serait un problème pour tout projet, cela est particulièrement préjudiciable dans le cas de la technologie ZK.

Par exemple, jetons un coup d’œil aux ZKEVM existants – des cumuls ZK qui reproduisent parfaitement le système d’exploitation d’Ethereum.

De nombreux ZKEVM s'appuient sur des circuits définis manuellement, qui nécessitent une implication humaine et utilisent des bibliothèques jeunes et non testées.

La probabilité que les développeurs commettent des erreurs dans cet environnement est élevée, ce qui rend les rollups ZK plus vulnérables au risque d'attaques.

Alors que les investisseurs s’entassent dans les rollups ZK, incités par d’éventuels largages de jetons, ils deviennent des cibles lucratives pour le prochain braquage majeur de crypto.

Solutions

La mise en œuvre de la sécurité au tout début du cycle de développement et de manière continue, par exemple via des bug bounties, peut aider à résoudre ce problème.

Il ne fait aucun doute que la technologie ZK change la donne pour Ethereum, et un développement constant est fondamental pour faire évoluer la blockchain.

Cependant, les solutions proposées par les rollups ZK sont à la hauteur de leur potentiel à causer des problèmes de sécurité.

Les startups doivent d’abord être honnêtes quant à savoir si elles utilisent la technologie ZK parce que c’est nécessaire ou parce qu’elles prennent le train en marche.

S’ils sont certains d’être les premiers, alors ils doivent être conscients des risques et construire avec la sécurité dès la conception est absolument fondamental.