Transcription de la conférence de Vitalik Buterin au Web3 Festival de Hong Kong : Nous avons besoin de protocoles capables d'atteindre les limites de la technologie cryptographique
TechFlow SélectionTechFlow Sélection
Transcription de la conférence de Vitalik Buterin au Web3 Festival de Hong Kong : Nous avons besoin de protocoles capables d'atteindre les limites de la technologie cryptographique
Nous devons vraiment commencer à étudier ce qu'est la limite supérieure, et comment nous pouvons réellement l'atteindre.
Dédié à des analyses Web3 approfondiesAuteur : Vitalik Buterin
Compilation : DeThings
Pendant le Web3 Festival Hong Kong 2024, Vitalik Buterin, cofondateur d'Ethereum, a prononcé une conférence principale intitulée « Reaching the Limits of Protocol Design » lors du « Web3 Scholars Summit 2024 », organisé par DRK Lab.
Voici le compte rendu en chinois de DeThings, avec des coupes :
Au cours des 10 dernières années, les types de technologies utilisées pour construire des protocoles ont considérablement évolué. Lorsque Bitcoin est apparu en 2009, il utilisait en réalité des techniques cryptographiques très simples : la seule cryptographie présente dans le protocole Bitcoin était les hachages et les signatures ECDSA sur courbes elliptiques, ainsi que la preuve de travail (PoW). La preuve de travail n'est qu'une autre utilisation des fonctions de hachage. Si l'on examine les types de technologies utilisés aujourd'hui dans les années 2020 pour construire des protocoles, on observe un ensemble bien plus sophistiqué de technologies, qui n'ont véritablement émergé que durant cette dernière décennie.
Ces technologies existaient déjà depuis longtemps au plan théorique — techniquement parlant, nous disposons du théorème PCP depuis des décennies. Depuis la découverte de Craig Gentry en 2009, nous avons le chiffrement homomorphe complet. Les circuits brouillés (garbled circuits), une forme de calcul à deux parties, existent aussi depuis des décennies. Mais il y a une différence entre l’existence théorique de ces technologies et leur existence pratique.
En réalité, je pense que le domaine des blockchains mérite une grande part du crédit : il a mobilisé d’importantes ressources, permettant à ces technologies d’atteindre un stade où elles peuvent être utilisées dans des applications courantes.
Construire une blockchain dans les années 2020 en supposant que les hachages et les signatures sont tout ce dont on dispose. En revanche, les protocoles observés dans les années 2020 considèrent dès le départ toutes ces nouvelles technologies comme des composants clés.
Le premier grand progrès ici est celui des ZK-SNARKs. Il s'agit d'une technologie permettant de prouver qu’un calcul a été effectué et qu’un certain résultat a été obtenu. On peut produire une preuve dont la vérification est beaucoup plus rapide que l’exécution directe du calcul. Et cela, sans divulguer les données d’entrée initiales.
La différence entre les ZK-SNARKs des années 2010 et ceux de 2016 — utilisés pour la première fois dans le protocole Zcash lancé en décembre 2016 — et les ZK-SNARKs actuels est énorme, n’est-ce pas ?
Ainsi, bon nombre de ces nouvelles formes de cryptographie sont passées de quasi-inconnues à des curiosités de niche, puis au courant dominant, devenant presque la norme par défaut aujourd’hui. Ces technologies ont connu d’énormes changements et améliorations au cours de la dernière décennie.
« Les ZK-SNARKs sont donc extrêmement utiles pour la confidentialité, mais aussi pour la scalabilité. Que font les blockchains ? Elles offrent de nombreux avantages : ouverture, accès sans permission, vérifiabilité globale. Mais tout cela se fait au prix de deux sacrifices majeurs.
L’un est la confidentialité, l’autre la scalabilité. Les ZK-SNARKs vous restituent la confidentialité, et ils vous restituent la scalabilité. En 2016, nous avons vu le protocole Zcash. Par la suite, nous avons commencé à observer de plus en plus d’applications dans l’écosystème Ethereum. Aujourd’hui, presque tout commence à utiliser zkSNARK, le calcul multipartite (MPC) et le chiffrement homomorphe complet (FHE). Les gens connaissent moins ces deux derniers que les zkSNARK, mais il existe certains cas d’usage impossibles à traiter avec les zkSNARKs seuls, par exemple le calcul privé sur des données personnelles.
Le vote constitue un cas d’usage important : on peut obtenir un certain niveau de confidentialité via les zk-SNARKs. Mais si l’on souhaite atteindre les meilleures propriétés possibles, alors il faut recourir au MPC (calcul multipartite) et au FHE (chiffrement homomorphe complet). De nombreuses applications d’intelligence artificielle cryptées finissent également par utiliser MPC et FHE — deux primitives dont l’efficacité a fortement augmenté ces dix dernières années. Le BLS (Boneh-Lynn-Shacham, signature agrégée) est une technologie intéressante qui permet essentiellement de rassembler un grand nombre de signatures provenant de milliers, voire dizaines de milliers, de participants différents, puis de vérifier cette signature combinée aussi rapidement que si c’était une seule signature.
Cette fonctionnalité est très puissante. L’agrégation BLS est en réalité au cœur du consensus proof-of-stake moderne d’Ethereum. Si l’on examine les consensus proof-of-stake créés avant l’agrégation BLS, leurs algorithmes ne supportaient souvent que quelques centaines de validateurs. Sur Ethereum, il y a actuellement environ 30 000 validateurs, chacun soumettant une signature toutes les 12 secondes. Cela n’est possible que grâce à cette nouvelle forme de cryptographie, qui n’a été réellement optimisée au point d’être utilisable que durant les 5 à 10 dernières années. Ces nouvelles technologies rendent possibles de nombreuses choses. »
Elles deviennent rapidement plus puissantes. Les protocoles actuels utilisent massivement toutes ces technologies. Nous avons vécu un passage majeur de la cryptographie spécialisée à la cryptographie générale — d’une cryptographie où il fallait comprendre soi-même comment elle fonctionnait pour créer un nouveau protocole, à une cryptographie générale où l’on conçoit des algorithmes dédiés à des applications spécifiques. Autrefois, il fallait créer un algorithme sur mesure pour chaque usage particulier. Aujourd’hui, même sans être cryptographe, on peut concevoir une application utilisant les technologies dont j’ai parlé ces cinq dernières minutes.
Il suffit d’écrire un bout de code, par exemple en Circom, puis Circom le compile en un vérificateur et un prouveur, et vous avez une application zk-SNARK. Quel est le défi ici ? Fondamentalement, c’est que nous avons parcouru un long chemin ces 10 dernières années. Qu’y a-t-il encore à faire ? Quelle est la distance qui sépare nos technologies actuelles de l’idéal théorique ? Je pense que c’est précisément là que les chercheurs et universitaires peuvent jouer un rôle crucial.
Je pense que les deux grands problèmes actuels sont fondamentalement : l’efficacité, et la sécurité. Il y a aussi un troisième problème, lié à l’extension des fonctionnalités.
Par exemple, nous ne maîtrisons pas encore vraiment la technique de l’obfuscation indistinguable. Si nous avions un algorithme réalisable, ce serait formidable. Mais en réalité, je pense qu’il est encore plus important d’améliorer l’efficacité et la sécurité de ce que nous avons aujourd’hui. »
Abordons l’efficacité. Prenons un exemple concret : la blockchain Ethereum. Sur Ethereum, le temps de slot est de 12 secondes. L’intervalle moyen entre un bloc et le suivant est de 12 secondes. Le temps normal de vérification d’un bloc — c’est-à-dire le temps nécessaire à tout nœud Ethereum pour valider un bloc — est d’environ 400 millisecondes.
Actuellement, la vérification d’un bloc Ethereum standard via zk-SNARK prend environ 20 minutes. Ce délai progresse vite : il était de 5 heures il y a deux ans. Maintenant, 20 minutes est la moyenne, d’accord ? Il existe encore des cas pires. Par exemple, si un bloc Ethereum entier consiste en des calculs Zcash, alors sa preuve prend plus de 20 minutes.
Mais comparé à il y a deux ans, nous avons fait beaucoup de chemin. Quel est l’objectif maintenant ? C’est la preuve en temps réel : quand un bloc est créé, avoir sa preuve avant que le prochain bloc soit produit. Qu’aurions-nous alors ? En gros, chaque utilisateur d’Ethereum pourrait facilement devenir un vérificateur complet du protocole, or très peu de personnes hébergent un nœud Ethereum. Un nœud archive nécessite actuellement 2 To — c’est faisable, mais peu efficace. Et si chaque portefeuille Ethereum, y compris les portefeuilles navigateurs, mobiles, ou légers intégrés à des contrats intelligents sur d’autres chaînes, pouvait réellement vérifier complètement les règles de consensus d’Ethereum ?
Certaines personnes ne font pas confiance à Infura. Elles ne font même pas confiance aux validateurs proof-of-stake d’Ethereum, et préfèrent vérifier directement les règles, assurer directement la validité des blocs Ethereum. Comment réaliser cela avec des zk-SNARK ? Pour y parvenir vraiment, la preuve zk-SNARK doit être en temps réel, et il doit exister un moyen pour que tout bloc Ethereum soit prouvé en moins de 5 secondes.
La question est : pouvons-nous y arriver ? Des problèmes similaires existent aussi pour le MPC et le FHE. Comme je l’ai mentionné, un cas d’usage typique du MPC et du FHE est le vote, et cela commence déjà à être utilisé. Il y a environ trois semaines, un événement Ethereum a eu lieu au Vietnam. Pendant cet événement, ils ont utilisé le MPC, l’un de ces systèmes de vote cryptographiquement sécurisés, pour voter sur les projets et les hackathons.
Le problème actuel du MPC est que certaines de ses propriétés de sécurité dépendent d’un serveur central. Peut-on décentraliser cette hypothèse de confiance ? Oui, mais cela nécessite le MPC et le FHE. Or, le coût de performance pour garantir ces protocoles est élevé, surtout quand on combine FHE et zk-SNARK. Pour que ces protocoles deviennent la norme par défaut pour les utilisateurs ordinaires, il ne faut pas que chaque bulletin de vote coûte 5 dollars en calcul, n’est-ce pas ? Il faut que cela puisse être fait rapidement, voire en temps réel pour des milliers de votes.
Alors, comment atteindre cet objectif zk-SNARK ? Je vois trois grandes catégories d’amélioration de l’efficacité. La première est la parallélisation et l’agrégation. Imaginez qu’un bloc Ethereum requiert jusqu’à 10 millions d’étapes de calcul. Vous prenez chaque étape, vous en faites une preuve séparée, puis vous agrégerez ces preuves. Prenez les deux premières, agrégées-les. Puis les deux suivantes, agrégées-les. Puis les deux suivantes, agrégées-les. Puis agrégées les agrégats des deux premières, et ainsi de suite, formant un arbre. Après environ 20 étapes dans cet arbre, vous obtenez une preuve unique représentant la validité complète du bloc.
Cela est faisable avec la technologie actuelle. On peut prouver la validité d’un bloc théorique en 5 secondes. Où est le problème ? Cela nécessite énormément de calcul parallèle, n’est-ce pas ? Il faut 10 millions de preuves. Peut-on l’optimiser ? Peut-on mieux paralléliser ? Mieux agrégater les preuves ? La réponse est oui. Il existe de nombreuses idées théoriques sur la manière de procéder. Mais cela doit devenir quelque chose de concret. C’est un problème mêlant amélioration algorithmique, optimisation bas niveau, conception matérielle et gains d’efficacité. Les ASIC sont donc très importants. Nous avons tous vu combien les ASIC sont cruciaux pour le minage, n’est-ce pas ? Souvenez-vous de 2013, quand les ASIC sont apparus, la puissance de calcul de Bitcoin a explosé.
Les ASIC sont très puissants : à coût matériel et électrique égal, un ASIC calcule environ 100 fois plus de hachages qu’un GPU. Alors, pouvons-nous apporter les mêmes bénéfices aux preuves SNARK ? Je pense que oui. De plus en plus d’entreprises commencent à fabriquer des ASIC spécialisés pour les preuves zk-SNARK. Cela pourrait concerner les zkEVM, mais devrait en réalité être très générique. Vous devriez pouvoir fabriquer un ASIC SNARK capable de prouver n’importe quel type de calcul. En faisant cela, pouvons-nous passer de 20 minutes à 5 secondes ?
Enfin, améliorer les algorithmes eux-mêmes. Nous avons Groth16, les tables de recherche, les SNARK 64 bits, les STARK, les STARK 32 bits, plein d’idées différentes. Peut-on encore améliorer l’efficacité des algorithmes SNARK ? Peut-on concevoir des fonctions de hachage plus adaptées aux SNARK, des algorithmes de signature plus compatibles ? Il y a beaucoup d’idées ici, et j’encourage vivement à y travailler.
Le principal problème de sécurité, c’est les bogues, n’est-ce pas ? Je pense que les bogues sont l’un des plus grands problèmes rarement discutés, pourtant extrêmement important. Nous disposons de toutes ces technologies cryptographiques impressionnantes, mais si les gens craignent un défaut dans le circuit, ils n’y feront pas confiance. Que ce soit zk-SNARK ou zkEVM, ils comportent environ 7000 lignes de code. Et encore, dans des cas très optimisés. En moyenne, il y a entre 15 et 50 bogues par 1000 lignes de code. Sur Ethereum, nous faisons des efforts pour descendre sous 15 bogues par 1000 lignes, mais toujours plus que zéro. Si un système gère des milliards de dollars, un seul bogue suffit à perdre tout cet argent, peu importe la sophistication de la cryptographie.
La question est : que pouvons-nous faire pour exploiter pleinement ces technologies cryptographiques et réduire les erreurs ? Actuellement, la technique de base est le comité de sécurité : vous réunissez simplement un groupe de personnes sur Ethereum, et si la majorité — disons plus de 75 % — pense qu’il y a un bogue, elles peuvent annuler ce que dit le système de preuve. C’est un système assez centralisé, mais c’est le meilleur que nous ayons pour l’instant. À court terme, nous aurons des preuves multiples. Voici un schéma de Starknet, un des rollups basés sur Ethereum. L’idée est que, si vous avez plusieurs systèmes de preuve, vous pouvez théoriquement utiliser la redondance pour réduire le risque de bogue dans l’un d’eux. Si vous en avez trois, et qu’un seul comporte une erreur, espérons que les deux autres ne commettent pas exactement la même erreur au même endroit.
Enfin, je pense qu’une direction intéressante pour l’avenir est l’utilisation d’outils d’intelligence artificielle, notamment pour la vérification formelle. Prouver mathématiquement, par exemple, qu’un zkEVM est exempt de bogues. Pouvez-vous prouver rigoureusement que l’implémentation zkEVM valide exactement la même fonctionnalité que l’implémentation Ethereum dans le code EVM ? Pouvez-vous prouver qu’elle donne un seul résultat pour toute entrée possible ? Si nous pouvions vraiment prouver ces choses, peut-être pourrions-nous un jour atteindre un monde avec des zkEVM sans bogues.
Ce serait fou, non ? Car auparavant, personne n’avait jamais construit un programme aussi complexe sans bogues. En 2019, personne ne pensait que l’IA pourrait produire de belles images, n’est-ce pas ? Aujourd’hui, nous voyons à quel point les progrès ont été rapides. Nous mesurons la puissance de l’IA. Maintenant, la question est : pouvons-nous appliquer des outils similaires à des tâches concrètes, comme générer automatiquement des preuves mathématiques pour des énoncés complexes couvrant des programmes de milliers de lignes ? Je pense que c’est un défi ouvert intéressant, digne d’attention.
Concernant l’efficacité des signatures agrégées, Ethereum compte aujourd’hui 30 000 validateurs. Exécuter un nœud est exigeant, n’est-ce pas ? J’ai un nœud Ethereum sur mon ordinateur portable, il fonctionne, mais ce n’est pas un ordinateur bon marché, et j’ai dû agrandir mon disque dur moi-même. L’objectif idéal d’Ethereum est de supporter autant de validateurs que possible.
Nous voulons démocratiser au maximum le proof-of-stake, permettre à chacun de participer au consensus, quel que soit son niveau. Nous voulons que l’exécution d’un nœud Ethereum soit très accessible, très simple. Nous voulons que la théorie et le protocole soient aussi simples que possible. Quelle est la limite théorique ici ? Chaque participant doit transmettre 1 bit par période, car il faut diffuser qui a signé et qui n’a pas signé.
C’est la limite fondamentale. Au-delà, il n’y a plus de limites : aucune borne inférieure sur le calcul. Vous pouvez faire des preuves agrégées, des arbres de preuves récursifs, des signatures, divers types d’agrégation. Vous pouvez utiliser des STARK, de la cryptographie basée sur les réseaux, des STARK 32 bits, ou diverses autres technologies.
La question est : jusqu’où pouvons-nous optimiser l’agrégation de signatures ? C’est la sécurité pair-à-pair. Les gens ne réfléchissent pas assez au réseau P2P. C’est un point que je veux souligner particulièrement. Dans le domaine cryptographique, on a tendance à construire des structures élaborées par-dessus le réseau P2P, puis à supposer que le réseau fonctionnera bien.
Or, cela cache de nombreux risques. Je pense que ces risques vont devenir plus complexes. Le réseau P2P fonctionne d’une certaine manière dans Bitcoin. Dans les années 2010, chaque nœud voyait tout. Bien sûr, on pouvait subir des attaques — attaques d’éclipse, attaques de déni de service, etc.
Mais lorsque le réseau est très simple, et que son unique mission est de s’assurer que tout le monde reçoive tout, le problème reste relativement simple. Le problème, c’est qu’avec la croissance d’Ethereum, le réseau P2P devient de plus en plus complexe. Le réseau P2P d’Ethereum compte aujourd’hui 64 fragments, n’est-ce pas ?
Pour l’agrégation de signatures, afin de traiter 30 000 signatures par période comme actuellement, nous avons un réseau P2P divisé en 64 sous-réseaux distincts, chaque nœud n’appartenant qu’à un ou quelques-uns d’entre eux. Dans l’échantillonnage de disponibilité des données — technique utilisée par Ethereum pour fournir de l’espace de données aux blocs afin d’assurer la scalabilité — ce sont ces deux projets qui permettent aux rollups d’avoir des frais très bas.
Cela repose aussi sur une architecture P2P plus complexe. Ici, vous voyez un graphe de nœuds pairs : dans ce dispositif, chaque nœud ne télécharge qu’un huitième des données totales. Alors, un tel réseau est-il vraiment sécurisé ? Pouvez-vous en garantir la sécurité ? Pouvez-vous maximiser le taux de garantie ? Comment pouvons-nous protéger et renforcer la sécurité du réseau P2P dont dépend Ethereum ?
Fondamentalement, je pense qu’à ce stade, nous devons viser des protocoles capables d’atteindre les limites de la cryptographie. Nos outils cryptographiques sont bien plus puissants qu’il y a dix ans, mais ils peuvent encore l’être davantage. À ce stade, nous devons commencer à étudier sérieusement : quelle est la limite supérieure ? Comment pouvons-nous vraiment l’atteindre ?
Deux domaines sont également cruciaux. Le premier est l’amélioration continue de l’efficacité : nous voulons des preuves en temps réel de tout. Nous voulons un monde où, dans les protocoles décentralisés, chaque message publié sur un blog serait accompagné par défaut d’un zk-SNARK prouvant que ce message, ainsi que tout ce sur quoi il s’appuie, respecte bien les règles du protocole.
Le deuxième domaine frontière est l’amélioration de la sécurité. Il s’agit fondamentalement de réduire au minimum les erreurs, pour que les technologies concrètes sur lesquelles reposent ces protocoles soient extrêmement robustes et dignes de confiance, au point que les gens puissent s’y fier pleinement. Pour l’instant, malgré les vulnérabilités, les gens ne font pas confiance à la cryptographie, mais continuent de faire confiance à des petits groupes humains.
Mais, comme nous l’avons vu maintes fois, les multisignatures peuvent aussi être piratées. Il existe de nombreux exemples, notamment parmi les projets dits Layer 2. Dans un ou deux projets, les jetons étaient contrôlés par une multisignature, mais mystérieusement, cinq des neuf gardiens ont été piratés simultanément, entraînant de lourdes pertes. Si nous voulons dépasser ce stade, nous devons faire confiance à ce qui peut réellement être mis en œuvre technologiquement, et faire respecter les règles par la cryptographie elle-même, plutôt que de compter sur un petit groupe d’individus pour garantir le respect des règles.
Mais pour cela, le code doit être digne de confiance. La question est : pouvons-nous rendre le code fiable ? Le réseau fiable ? L’économie de ces produits et protocoles fiable ? Je pense que ce sont là les défis fondamentaux. J’espère que nous continuerons à travailler ensemble pour progresser. Merci.
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
@DethingsNews
