Vitalik sur les futurs possibles d’Ethereum (VI) : The Splurge

Dans la conception du protocole Ethereum, environ la moitié du contenu concerne différents types d'améliorations de l'EVM, tandis que le reste est constitué de divers sujets de niche, c'est là que réside la signification de la « Splurge ».

Titre original : « Possible futures of the Ethereum protocol, part 6: The Splurge »

Auteur : Vitalik Buterin

Traduction : zhouzhou, BlockBeats

Voici le contenu original (légèrement réorganisé pour faciliter la lecture et la compréhension) :

Certains éléments sont difficiles à classer dans une seule catégorie. Dans la conception du protocole Ethereum, de nombreux « détails » sont très importants pour le succès d'Ethereum. En réalité, environ la moitié du contenu concerne différents types d'améliorations de l'EVM, tandis que le reste est constitué de divers sujets de niche, c'est là que réside la signification de la « Splurge ».

Feuille de route 2023 : The Splurge

Splurge : Objectifs clés

• Faire de l'EVM un « état final » performant et stable
• Introduire l'abstraction de compte dans le protocole, permettant à tous les utilisateurs de bénéficier de comptes plus sûrs et plus pratiques
• Optimiser l'économie des frais de transaction, améliorer l'évolutivité tout en réduisant les risques
• Explorer la cryptographie avancée pour améliorer significativement Ethereum à long terme

Améliorations de l'EVM

Quels problèmes cela résout-il ?

Actuellement, l'EVM est difficile à analyser statiquement, ce qui complique la création d'implémentations efficaces, la vérification formelle du code et l'extension ultérieure. De plus, l'efficacité de l'EVM est faible, rendant difficile la mise en œuvre de nombreuses formes de cryptographie avancée, sauf si elle est explicitement prise en charge par des précompilés.

Qu'est-ce que c'est et comment cela fonctionne-t-il ?

La première étape de la feuille de route actuelle d'amélioration de l'EVM est le format d'objet EVM (EOF), qui est prévu pour être inclus dans le prochain hard fork. EOF est une série d'EIP qui spécifient une nouvelle version du code EVM avec de nombreuses caractéristiques uniques, dont les plus remarquables sont :

• Séparation entre le code (exécutable mais non lisible depuis l'EVM) et les données (lisibles mais non exécutables)
• Interdiction des sauts dynamiques, seuls les sauts statiques sont autorisés
• Le code EVM ne peut plus observer les informations liées au gas
• Ajout d'un nouveau mécanisme explicite de sous-routine

Structure du code EOF

Splurge : Améliorations de l'EVM (suite)

Les anciens contrats continueront d'exister et pourront être créés, bien qu'ils puissent être progressivement abandonnés à terme (voire convertis de force en code EOF). Les nouveaux contrats bénéficieront de l'efficacité accrue apportée par EOF — d'abord via des bytecodes légèrement réduits grâce aux sous-routines, puis via de nouvelles fonctionnalités spécifiques à EOF ou une réduction du coût en gas.

Après l'introduction d'EOF, les mises à niveau ultérieures deviennent plus faciles. La plus avancée actuellement est l'extension arithmétique modulaire de l'EVM (EVM-MAX). EVM-MAX crée un ensemble d'opérations dédiées aux calculs modulaires et les place dans un nouvel espace mémoire inaccessible par d'autres opcodes, permettant ainsi des optimisations telles que la multiplication de Montgomery.

Une idée plus récente est de combiner EVM-MAX avec la fonctionnalité SIMD (Single Instruction Multiple Data). SIMD est un concept présent dans Ethereum depuis longtemps, proposé initialement par Greg Colvin dans l'EIP-616. SIMD peut accélérer de nombreuses formes de cryptographie, y compris les fonctions de hachage, les STARKs 32 bits et la cryptographie basée sur les réseaux. La combinaison d'EVM-MAX et de SIMD rend ces deux extensions axées sur la performance naturellement complémentaires.

La conception approximative d'un EIP combiné partirait de l'EIP-6690, puis :

• Permettre (i) tout nombre impair ou (ii) toute puissance de 2 jusqu'à 2768 comme module
• Pour chaque opcode EVM-MAX (addition, soustraction, multiplication), ajouter une version qui n'utilise plus 3 immédiats x, y, z, mais 7 immédiats : x_start, x_skip, y_start, y_skip, z_start, z_skip, count. En code Python, ces opcodes fonctionnent comme suit :

for i in range(count):

mem[z_start + z_skip * count] = op(

mem[x_start + x_skip * count],

mem[y_start + y_skip * count]

)

Dans l'implémentation réelle, cela sera traité de manière parallèle.

• Possibilité d'ajouter XOR, AND, OR, NOT et SHIFT (y compris circulaire et non circulaire), au moins pour les modules puissance de 2. Ajouter également ISZERO (qui pousse la sortie sur la pile principale de l'EVM), ce qui sera suffisamment puissant pour permettre la cryptographie sur courbes elliptiques, la cryptographie sur petits domaines (comme Poseidon, Circle STARKs), les fonctions de hachage traditionnelles (SHA256, KECCAK, BLAKE) et la cryptographie basée sur les réseaux. D'autres mises à niveau de l'EVM sont également possibles, mais ont reçu moins d'attention jusqu'à présent.

Liens vers les recherches existantes

• EOF: 
• EVM-MAX: 
• SIMD: 

Travaux restants et compromis

Actuellement, EOF est prévu pour être inclus dans le prochain hard fork. Il est toujours possible de le retirer à la dernière minute — des fonctionnalités ont déjà été retirées temporairement lors de hard forks précédents — mais cela représenterait un grand défi. Retirer EOF signifierait que toute future mise à niveau de l'EVM devrait se faire sans EOF, ce qui est possible mais probablement plus difficile.

Le principal compromis de l'EVM réside dans la complexité du L1 par rapport à la complexité de l'infrastructure. EOF nécessite beaucoup de code à ajouter à l'implémentation de l'EVM, et la vérification statique du code est relativement complexe. Cependant, en échange, nous pouvons simplifier les langages de haut niveau, simplifier l'implémentation de l'EVM et obtenir d'autres avantages. On peut dire que la feuille de route qui privilégie l'amélioration continue du L1 d'Ethereum devrait inclure et se baser sur EOF.

Un travail important à réaliser est la mise en œuvre de fonctionnalités similaires à EVM-MAX + SIMD, et le benchmarking de la consommation de gas pour diverses opérations cryptographiques.

Comment cela interagit-il avec les autres parties de la feuille de route ?

L'ajustement du L1 de son EVM permet également au L2 de s'ajuster plus facilement en conséquence. Si les deux ne sont pas synchronisés, cela peut entraîner des incompatibilités et des effets négatifs. De plus, EVM-MAX et SIMD peuvent réduire le coût en gas de nombreux systèmes de preuve, rendant le L2 plus efficace. Cela facilite également le remplacement de davantage de précompilés par du code EVM capable d'exécuter les mêmes tâches, sans affecter significativement l'efficacité.

Abstraction de compte

Quels problèmes cela résout-il ?

Actuellement, les transactions ne peuvent être vérifiées que d'une seule manière : la signature ECDSA. À l'origine, l'abstraction de compte visait à dépasser cette limitation, permettant à la logique de vérification d'un compte d'être n'importe quel code EVM. Cela peut permettre une série d'applications :

• Passer à la cryptographie résistante aux ordinateurs quantiques
• Rotation des anciennes clés (largement considérée comme une bonne pratique de sécurité)
• Portefeuilles multi-signatures et portefeuilles à récupération sociale
• Utiliser une clé pour les opérations de faible valeur, une autre (ou un ensemble de clés) pour les opérations de grande valeur

Permettre aux protocoles de confidentialité de fonctionner sans relai, réduisant considérablement leur complexité et éliminant un point central de dépendance

Depuis la proposition de l'abstraction de compte en 2015, ses objectifs se sont également étendus à de nombreux « objectifs de commodité », par exemple, permettre à un compte sans ETH mais possédant des ERC20 de payer le gas en ERC20. Voici un graphique récapitulatif de ces objectifs :

MPC (calcul multipartite) est une technologie vieille de 40 ans, utilisée pour diviser une clé en plusieurs parties et les stocker sur plusieurs appareils, générant des signatures à l'aide de techniques cryptographiques sans jamais combiner directement ces parties de clé.

L'EIP-7702 est une proposition prévue pour être introduite lors du prochain hard fork. Elle est le résultat d'une prise de conscience croissante de la nécessité d'offrir la commodité de l'abstraction de compte à tous les utilisateurs (y compris les utilisateurs EOA), visant à améliorer l'expérience utilisateur à court terme et à éviter une scission en deux écosystèmes.

Ce travail a commencé avec l'EIP-3074 et a finalement abouti à l'EIP-7702. L'EIP-7702 offre les « fonctionnalités de commodité » de l'abstraction de compte à tous les utilisateurs, y compris les EOA (comptes détenus à l'extérieur, contrôlés par des signatures ECDSA).

Comme le montre le graphique, bien que certains défis (notamment ceux liés à la « commodité ») puissent être résolus par des techniques progressives telles que le calcul multipartite ou l'EIP-7702, les principaux objectifs de sécurité qui ont motivé la proposition initiale d'abstraction de compte ne peuvent être atteints qu'en revenant à la racine du problème : permettre au code de contrat intelligent de contrôler la vérification des transactions. La raison pour laquelle cela n'a pas encore été réalisé est la difficulté d'une mise en œuvre sécurisée.

Qu'est-ce que c'est et comment cela fonctionne-t-il ?

Le cœur de l'abstraction de compte est simple : permettre aux contrats intelligents d'initier des transactions, et pas seulement aux EOA. Toute la complexité réside dans la manière de le faire tout en maintenant un réseau décentralisé et en se protégeant contre les attaques par déni de service.

Un défi clé typique est le problème des échecs multiples :

Si la fonction de vérification de 1000 comptes dépend d'une seule valeur S, et que la valeur actuelle de S rend toutes les transactions du mempool valides, alors une seule transaction qui inverse la valeur de S peut invalider toutes les autres transactions du mempool. Cela permet à un attaquant d'envoyer des transactions indésirables dans le mempool à très faible coût, saturant ainsi les ressources des nœuds du réseau.

Après des années d'efforts pour étendre les fonctionnalités tout en limitant les risques de déni de service (DoS), la solution pour réaliser « l'abstraction de compte idéale » a finalement été trouvée : ERC-4337.

ERC-4337 fonctionne en divisant le traitement des opérations utilisateur en deux étapes : vérification et exécution. Toutes les vérifications sont traitées en premier, puis toutes les exécutions. Dans le mempool, une opération utilisateur n'est acceptée que si la phase de vérification n'implique que son propre compte et ne lit pas de variables d'environnement. Cela empêche les attaques par échecs multiples. De plus, une limite stricte de gas est imposée à l'étape de vérification.

ERC-4337 a été conçu comme une norme de protocole supplémentaire (ERC), car à l'époque, les développeurs clients d'Ethereum se concentraient sur la fusion (Merge) et n'avaient pas de ressources pour d'autres fonctionnalités. C'est pourquoi ERC-4337 utilise des objets appelés opérations utilisateur plutôt que des transactions classiques. Cependant, nous avons récemment réalisé qu'il était nécessaire d'intégrer au moins une partie de ces fonctionnalités dans le protocole.

Deux raisons clés :

1. L'inefficacité inhérente d'EntryPoint en tant que contrat : chaque bundle a un surcoût fixe d'environ 100 000 gas, plus plusieurs milliers de gas supplémentaires par opération utilisateur.
2. Nécessité de garantir les propriétés d'Ethereum : par exemple, les garanties d'inclusion créées par la liste d'inclusion doivent être transférées aux utilisateurs de l'abstraction de compte.

De plus, ERC-4337 étend deux fonctionnalités :

• Paymasters : permet à un compte de payer les frais pour un autre, ce qui viole la règle selon laquelle la phase de vérification ne peut accéder qu'au compte de l'expéditeur. Un traitement spécial est donc introduit pour garantir la sécurité du mécanisme de paymaster.
• Aggregators : prend en charge l'agrégation de signatures, comme l'agrégation BLS ou basée sur SNARK. Ceci est nécessaire pour obtenir la meilleure efficacité des données sur les rollups.

Liens vers les recherches existantes

• Présentation sur l'histoire de l'abstraction de compte :
• ERC-4337 :
• EIP-7702 :
• Code BLSWallet (utilisant l'agrégation) :
• EIP-7562 (abstraction de compte écrite dans le protocole) :
• EIP-7701 (abstraction de compte écrite dans le protocole basée sur EOF) :

Travaux restants et compromis

Le principal défi actuel est de savoir comment intégrer pleinement l'abstraction de compte dans le protocole. L'EIP d'abstraction de compte écrite dans le protocole récemment populaire est l'EIP-7701, qui implémente l'abstraction de compte au-dessus d'EOF. Un compte peut avoir une section de code distincte pour la vérification ; si le compte définit cette section, elle sera exécutée lors de la vérification des transactions provenant de ce compte.

L'intérêt de cette approche est qu'elle montre clairement deux perspectives équivalentes de l'abstraction de compte native :

1. Inclure EIP-4337 dans le protocole
2. Un nouveau type d'EOA où l'algorithme de signature est l'exécution de code EVM

Si nous commençons par fixer des limites strictes à la complexité du code exécutable pendant la vérification — pas d'accès à l'état externe, et même une limite de gas initiale si basse qu'elle ne permet pas la résistance quantique ou les applications de confidentialité — alors la sécurité de cette approche est très claire : il s'agit simplement de remplacer la vérification ECDSA par une exécution de code EVM de durée similaire.

Cependant, avec le temps, nous devrons assouplir ces limites, car permettre aux applications de confidentialité de fonctionner sans relai et la résistance quantique sont très importants. Pour cela, nous devons trouver des moyens plus flexibles de gérer les risques de DoS, sans exiger que la vérification soit extrêmement simple.

Le principal compromis semble être « écrire rapidement une solution qui satisfait moins de gens » contre « attendre plus longtemps pour une solution potentiellement idéale ». La méthode idéale pourrait être une approche hybride. Une approche hybride consisterait à écrire plus rapidement certains cas d'utilisation et à laisser plus de temps pour explorer d'autres cas. Une autre méthode serait de déployer d'abord une version plus ambitieuse de l'abstraction de compte sur L2. Cependant, cela pose le défi que les équipes L2 doivent avoir confiance dans la proposition pour l'adopter, surtout pour garantir que le L1 et/ou d'autres L2 pourront adopter une solution compatible à l'avenir.

Un autre cas d'utilisation à considérer explicitement est celui des comptes de stockage de clés, qui stockent l'état du compte sur L1 ou un L2 dédié, mais peuvent être utilisés sur L1 et tout L2 compatible. Pour que cela fonctionne efficacement, il peut être nécessaire que le L2 prenne en charge des opcodes comme L1SLOAD ou REMOTESTATICCALL, mais cela nécessite également que l'implémentation de l'abstraction de compte sur L2 prenne en charge ces opérations.

Comment cela interagit-il avec les autres parties de la feuille de route ?

La liste d'inclusion doit prendre en charge les transactions d'abstraction de compte. En pratique, les besoins de la liste d'inclusion sont très similaires à ceux d'un mempool décentralisé, bien que la liste d'inclusion soit un peu plus flexible. De plus, l'implémentation de l'abstraction de compte devrait être coordonnée autant que possible entre L1 et L2. Si, à l'avenir, la plupart des utilisateurs utilisent des rollups de stockage de clés, la conception de l'abstraction de compte doit en tenir compte.

Améliorations de l'EIP-1559

Quels problèmes cela résout-il ?

L'EIP-1559 a été activé sur Ethereum en 2021, améliorant considérablement le temps moyen d'inclusion des blocs.

Temps d'attente

Cependant, la mise en œuvre actuelle de l'EIP-1559 présente plusieurs imperfections :

1. La formule est légèrement défectueuse : elle ne vise pas 50 % de blocs pleins, mais environ 50-53 %, selon la variance (ceci est lié à l'inégalité arithmético-géométrique en mathématiques).
2. L'ajustement n'est pas assez rapide dans les cas extrêmes.

La formule utilisée pour les blobs (EIP-4844) a été spécialement conçue pour résoudre le premier problème et est globalement plus simple. Cependant, ni l'EIP-1559 ni l'EIP-4844 n'ont tenté de résoudre le second problème. Ainsi, la situation actuelle est un état intermédiaire confus, impliquant deux mécanismes différents, et il existe une opinion selon laquelle, avec le temps, les deux devront être améliorés.

De plus, il existe d'autres faiblesses dans la tarification des ressources d'Ethereum non liées à l'EIP-1559, mais qui peuvent être résolues par des ajustements de l'EIP-1559. L'un des principaux problèmes est la différence entre le cas moyen et le pire cas : le prix des ressources dans Ethereum doit être fixé pour gérer le pire cas, c'est-à-dire un bloc utilisant tout le gas pour une seule ressource, mais l'utilisation moyenne réelle est bien inférieure, ce qui entraîne une inefficacité.

Qu'est-ce que le Gas multidimensionnel et comment cela fonctionne-t-il ?

La solution à ces inefficacités est le Gas multidimensionnel : fixer des prix et des limites différents pour différentes ressources. Ce concept est techniquement indépendant de l'EIP-1559, mais l'existence de l'EIP-1559 facilite sa mise en œuvre. Sans l'EIP-1559, le conditionnement optimal d'un bloc avec plusieurs contraintes de ressources est un problème complexe de sac à dos multidimensionnel. Avec l'EIP-1559, la plupart des blocs ne saturent aucune ressource, donc un algorithme simple « accepter toute transaction payant suffisamment » suffit.

Nous avons déjà du Gas multidimensionnel pour l'exécution et les blobs de données ; en principe, nous pouvons l'étendre à d'autres dimensions : calldata (données de transaction), lecture/écriture d'état, et expansion de la taille de l'état.

L'EIP-7706 introduit une nouvelle dimension de gas, dédiée au calldata. Il simplifie également le mécanisme de Gas multidimensionnel en unifiant les trois types de gas dans un cadre de style EIP-4844, résolvant ainsi le défaut mathématique de l'EIP-1559. L'EIP-7623 est une solution plus précise, ciblant le problème des ressources cas moyen/pire cas, en limitant plus strictement le calldata maximal sans introduire une nouvelle dimension entière.

Une direction de recherche supplémentaire consiste à résoudre le problème du taux de mise à jour, en recherchant un algorithme de calcul du coût de base plus rapide tout en conservant les invariants clés introduits par le mécanisme EIP-4844 (c'est-à-dire : à long terme, l'utilisation moyenne est exactement proche de la valeur cible).

Liens vers les recherches existantes

• FAQ EIP-1559: 
• Analyse empirique de l'EIP-1559: 
• Propositions d'amélioration pour un ajustement rapide: 
• Section sur le mécanisme de coût de base dans la FAQ EIP-4844: 
• EIP-7706: 
• EIP-7623: 
• Gas multidimensionnel: 

Quels sont les travaux restants et les compromis ?

Les principaux compromis du Gas multidimensionnel sont :

1. Augmentation de la complexité du protocole : l'introduction du Gas multidimensionnel rend le protocole plus complexe.
2. Augmentation de la complexité de l'algorithme optimal pour remplir les blocs : l'algorithme optimal pour remplir les blocs à pleine capacité devient également plus complexe.

La complexité du protocole est relativement faible pour le calldata, mais elle augmente pour les dimensions de gas internes à l'EVM (comme la lecture et l'écriture du stockage). Le problème est que non seulement les utilisateurs fixent des limites de gas, mais les contrats fixent également des limites lors de l'appel d'autres contrats. Actuellement, ils ne peuvent fixer des limites que de manière unidimensionnelle.

Une solution simple consiste à rendre le Gas multidimensionnel disponible uniquement à l'intérieur d'EOF, car EOF n'autorise pas les contrats à fixer des limites de gas lors de l'appel d'autres contrats. Les contrats non EOF doivent payer tous les types de gas lors des opérations de stockage (par exemple, si SLOAD utilise 0,03 % de la limite de gas d'accès au stockage du bloc, les utilisateurs non EOF paieront également 0,03 % de la limite de gas d'exécution).

Davantage de recherches sur le Gas multidimensionnel aideront à comprendre ces compromis et à trouver le point d'équilibre idéal.

Comment cela interagit-il avec les autres parties de la feuille de route ?

La mise en œuvre réussie du Gas multidimensionnel peut considérablement réduire l'utilisation des ressources dans certains « pires cas », réduisant ainsi la pression pour optimiser les performances afin de prendre en charge, par exemple, des arbres binaires basés sur des hash STARKed. Fixer un objectif clair pour la croissance de la taille de l'état facilitera la planification et l'estimation des besoins pour les développeurs clients à l'avenir.

Comme mentionné précédemment, l'existence d'EOF facilite la mise en œuvre de versions plus extrêmes du Gas multidimensionnel grâce à sa propriété de non-observabilité du gas.

Fonctions de délai vérifiables (VDFs)

Quels problèmes cela résout-il ?

Actuellement, Ethereum utilise la randomisation basée sur RANDAO pour sélectionner les proposeurs. La randomisation de RANDAO fonctionne en exigeant que chaque proposeur révèle un secret auquel il s'est engagé à l'avance, chaque secret révélé étant mélangé à la randomisation.

Chaque proposeur a donc un « pouvoir de manipulation d'un bit » : il peut modifier la randomisation en ne se présentant pas (ce qui a un coût). Cette méthode est raisonnable pour la sélection des proposeurs, car il est très rare de renoncer à une opportunité pour en obtenir deux nouvelles. Mais pour les applications on-chain nécessitant de la randomisation, ce n'est pas idéal. Idéalement, nous devrions trouver une source de randomisation plus robuste.

Qu'est-ce qu'une VDF et comment cela fonctionne-t-il ?

Une fonction de délai vérifiable est une fonction qui ne peut être calculée que séquentiellement, sans accélération par parallélisation. Un exemple simple est le hachage répété : for i in range(10**9): x = hash(x). Le résultat, prouvé correct par SNARK, peut être utilisé comme valeur aléatoire.

L'idée est de choisir une entrée basée sur les informations disponibles à l'instant T, alors que la sortie n'est pas encore connue à T : la sortie ne sera disponible qu'après que quelqu'un ait exécuté le calcul complet après T. Comme n'importe qui peut exécuter le calcul, il n'est pas possible de cacher le résultat, donc il n'y a pas de possibilité de manipulation.

Le principal risque des VDF est l'optimisation inattendue : quelqu'un découvre comment exécuter la fonction plus rapidement que prévu, manipulant ainsi les informations révélées à l'instant T.

L'optimisation inattendue peut se produire de deux manières :

1. Accélération matérielle : quelqu'un fabrique un ASIC capable d'exécuter la boucle de calcul plus rapidement que le matériel existant.
2. Parallélisation inattendue : quelqu'un trouve un moyen d'exécuter la fonction plus rapidement en la parallélisant, même si cela nécessite 100 fois plus de ressources.

La tâche de créer une VDF réussie est d'éviter ces deux problèmes tout en restant efficace (par exemple, la preuve SNARK en temps réel d'un hachage nécessite du matériel lourd). L'accélération matérielle est généralement résolue par un acteur d'intérêt public qui crée et distribue lui-même un ASIC VDF proche de l'optimal.

Liens vers les recherches existantes

• Site de recherche VDF: 
• Réflexions sur les attaques VDF dans Ethereum, 2018: 
• Attaque sur la VDF MinRoot proposée: 

Quels sont les travaux restants et les compromis ?

Actuellement, aucune construction VDF ne répond pleinement à toutes les exigences des chercheurs Ethereum. Il reste du travail à faire pour trouver une telle fonction. Si elle est trouvée, le principal compromis sera de décider de l'intégrer ou non : un compromis simple entre fonctionnalité, complexité du protocole et risques de sécurité.

Si nous pensons qu'une VDF est sûre mais qu'elle ne l'est finalement pas, selon la manière dont elle est implémentée, la sécurité retombera sur l'hypothèse RANDAO (un bit de pouvoir de manipulation par attaquant) ou un peu pire. Ainsi, même si la VDF échoue, elle ne compromettra pas le protocole, mais affectera les applications ou nouvelles fonctionnalités du protocole qui en dépendent fortement.

Comment cela interagit-il avec les autres parties de la feuille de route ?

La VDF est un composant relativement autonome du protocole Ethereum. Outre l'amélioration de la sécurité de la sélection des proposeurs, elle a des applications dans (i) les applications on-chain nécessitant de la randomisation et (ii) les mempools cryptographiques, bien que la création de mempools cryptographiques basés sur VDF dépende encore de découvertes cryptographiques supplémentaires qui n'ont pas encore eu lieu.

Un point à garder à l'esprit est qu'en raison de l'incertitude matérielle, il y aura un certain « décalage » entre la production de la sortie VDF et le besoin de cette sortie. Cela signifie que l'information sera disponible quelques blocs à l'avance. Cela peut être un coût acceptable, mais doit être pris en compte dans la conception de la finalité à un slot ou de la sélection des comités.

Obfuscation et signatures à usage unique : l'avenir lointain de la cryptographie

Quels problèmes cela résout-il ?

L'un des articles les plus célèbres de Nick Szabo est son essai de 1997 sur le « protocole de Dieu ». Dans cet essai, il souligne que de nombreuses applications multipartites reposent sur un « tiers de confiance » pour gérer les interactions. Selon lui, le rôle de la cryptographie est de créer un tiers de confiance simulé, accomplissant le même travail sans avoir à faire confiance à un participant particulier.

Jusqu'à présent, nous n'avons pu réaliser cet idéal que partiellement. Si tout ce dont nous avons besoin est une machine virtuelle transparente dont les données et les calculs ne peuvent être arrêtés, censurés ou falsifiés, et que la confidentialité n'est pas un objectif, alors la blockchain peut atteindre cet objectif, bien que son évolutivité soit limitée.

Si la confidentialité est un objectif, jusqu'à récemment, nous ne pouvions développer que quelques protocoles spécifiques à certaines applications : signatures numériques pour l'authentification de base, signatures en anneau et signatures en anneau chaînables pour l'anonymat brut, cryptographie basée sur l'identité pour un chiffrement plus pratique sous certaines hypothèses de confiance, et signatures aveugles pour la monnaie électronique de type Chaum, etc. Cette approche exigeait beaucoup de travail pour chaque nouvelle application.

Dans les années 2010, nous avons eu un premier aperçu d'une méthode différente et plus puissante, basée sur la cryptographie programmable. Plutôt que de créer un nouveau protocole pour chaque application, nous pouvons utiliser de puissants nouveaux protocoles — en particulier les ZK-SNARKs — pour ajouter des garanties cryptographiques à n'importe quel programme.

Les ZK-SNARKs permettent à un utilisateur de prouver n'importe quelle déclaration sur les données qu'il détient, et la preuve (i) est facile à vérifier et (ii) ne révèle aucune donnée autre que la déclaration elle-même. C'est une avancée majeure en matière de confidentialité et d'évolutivité, comparable à l'impact des transformers en intelligence artificielle. Des milliers d'années-homme de travail spécifique à l'application sont soudainement remplacées par cette solution générale, capable de traiter des problèmes d'une ampleur inattendue.

Cependant, les ZK-SNARKs ne sont que la première des trois primitives universelles extrêmement puissantes de ce type. Ces protocoles sont si puissants qu'ils me rappellent un ensemble de cartes très puissantes dans Yu-Gi-Oh! — un jeu de cartes et une émission télé que je regardais enfant : les cartes des Dieux égyptiens.

Les cartes des Dieux égyptiens sont trois cartes extrêmement puissantes, dont la création est légendairement dangereuse, et leur puissance est telle qu'elles sont interdites en duel. De même, en cryptographie, nous avons ce trio de protocoles « Dieux égyptiens » :

Qu'est-ce que les ZK-SNARKs et comment cela fonctionne-t-il ?

Les ZK-SNARKs sont l'un des trois protocoles que nous possédons déjà, avec un niveau de maturité élevé. Au cours des cinq dernières années, l'augmentation spectaculaire de la vitesse des prouveurs et de la convivialité pour les développeurs a fait des ZK-SNARKs la pierre angulaire de la stratégie d'évolutivité et de confidentialité d'Ethereum. Mais les ZK-SNARKs ont une limitation importante : il faut connaître les données pour pouvoir les prouver. Dans chaque application ZK-SNARK, l'état doit avoir un « propriétaire » unique, qui doit être présent pour autoriser la lecture ou l'écriture de cet état.

Le deuxième protocole, qui n'a pas cette limitation, est le chiffrement totalement homomorphe (FHE). FHE permet d'effectuer n'importe quel calcul sur des données chiffrées sans les voir. Cela permet d'effectuer des calculs sur les données des utilisateurs, dans leur intérêt, tout en préservant la confidentialité des données et des algorithmes.

Il permet également d'étendre des systèmes de vote comme MACI pour obtenir des garanties de sécurité et de confidentialité presque parfaites. Longtemps considéré comme trop inefficace pour être utilisé, le FHE est désormais suffisamment performant pour des applications réelles.

Cursive est une application qui utilise le calcul multipartite et le chiffrement totalement homomorphe (FHE) pour la découverte d'intérêts communs avec confidentialité.

Cependant, le FHE a aussi ses limites : toute technologie basée sur le FHE nécessite encore que quelqu'un détienne la clé de déchiffrement. Cela peut être une configuration distribuée M-of-N, ou vous pouvez utiliser des environnements d'exécution de confiance (TEE) pour une deuxième couche de protection, mais cela reste une limitation.

Vient ensuite le troisième protocole, plus puissant que la combinaison des deux premiers : l'obfuscation indiscernable (indistinguishability obfuscation). Bien que cette technologie soit encore loin d'être mature, depuis 2020, nous avons des protocoles théoriquement valides basés sur des hypothèses de sécurité standard, et des efforts de mise en œuvre ont récemment commencé.

L'obfuscation indiscernable permet de créer un « programme chiffré » qui exécute n'importe quel calcul tout en cachant tous les détails internes du programme. Par exemple, vous pouvez placer une clé privée dans un programme obfusqué qui ne permet de l'utiliser que pour signer des nombres premiers, puis distribuer ce programme à d'autres. Ils peuvent signer n'importe quel nombre premier, mais ne peuvent pas extraire la clé. Mais ses capacités vont bien au-delà : combinée au hachage, elle peut être utilisée pour implémenter toute autre primitive cryptographique, et plus encore.

La seule chose que l'obfuscation indiscernable ne peut pas faire, c'est empêcher le programme d'être copié. Mais pour cela, il existe des technologies encore plus puissantes à l'horizon, bien qu'elles dépendent de la possession universelle d'ordinateurs quantiques : les signatures à usage unique quantiques (quantum one-shot signatures).

En combinant l'obfuscation et les signatures à usage unique, nous pouvons construire un tiers de confiance presque parfait. Le seul objectif que la cryptographie seule ne peut atteindre reste la résistance à la censure, garantie par la blockchain. Ces technologies peuvent non seulement rendre Ethereum lui-même plus sûr, mais aussi permettre la création d'applications plus puissantes.

Pour mieux comprendre comment ces primitives ajoutent des capacités, prenons le vote comme exemple clé. Le vote est un problème intéressant car il nécessite de nombreuses propriétés de sécurité complexes, y compris une vérifiabilité et une confidentialité très fortes. Bien que des protocoles de vote très sûrs existent depuis des décennies, nous pouvons nous lancer le défi de concevoir un protocole capable de gérer n'importe quel type de vote : vote quadratique, financement quadratique pairwise, financement quadratique en grappes, etc. En d'autres termes, nous voulons que l'étape de « comptage » soit un programme arbitraire.

Supposons d'abord que nous publions les résultats du vote sur la blockchain. Cela nous donne la vérifiabilité publique (n'importe qui peut vérifier que le résultat final est correct, y compris les règles de comptage et d'éligibilité) et la résistance à la censure (personne ne peut empêcher de voter). Mais il n'y a pas de confidentialité.

Ensuite, nous ajoutons les ZK-SNARKs, ce qui nous donne la confidentialité : chaque vote est anonyme, tout en garantissant que seuls les électeurs autorisés peuvent voter et qu'un électeur ne peut voter qu'une fois.

Ensuite, nous introduisons le mécanisme MACI, où les votes sont chiffrés pour la clé de déchiffrement d'un serveur central. Le serveur central effectue le comptage, y compris l'élimination des votes en double, et publie une preuve ZK-SNARK du résultat. Cela conserve les garanties précédentes (même si le serveur triche !), mais si le serveur est honnête, cela ajoute une garantie d'anti-coercition : les utilisateurs ne peuvent pas prouver comment ils ont voté, même s'ils le souhaitent. En effet, bien qu'ils puissent prouver qu'ils ont voté, ils ne peuvent pas prouver qu'ils n'ont pas voté pour annuler ce vote. Cela empêche la corruption et d'autres attaques.

Nous exécutons le comptage dans le FHE, puis effectuons un déchiffrement seuil N/2-of-N. Cela fait passer la garantie d'anti-coercition à N/2-of-N au lieu de 1-of-1.

Nous obfusquons le programme de comptage et concevons le programme obfusqué pour qu'il ne puisse produire un résultat que s'il est autorisé, par exemple par une preuve de consensus blockchain, une preuve de travail, ou une combinaison des deux. Cela rend la garantie d'anti-coercition presque parfaite : dans le cas du consensus blockchain, il faudrait que 51 % des validateurs conspirent ; dans le cas de la preuve de travail, même si tout le monde conspire, recalculer le comptage avec différents sous-ensembles d'électeurs pour tenter d'extraire le comportement d'un électeur serait extrêmement coûteux. Nous pouvons même faire en sorte que le programme ajoute un léger bruit aléatoire au résultat final pour rendre l'extraction du comportement d'un électeur encore plus difficile.

Nous ajoutons des signatures à usage unique, une primitive dépendant de l'informatique quantique, qui permet de signer une seule fois pour un type d'information spécifique. Cela rend la garantie d'anti-coercition véritablement parfaite.

L'obfuscation indiscernable permet également d'autres applications puissantes. Par exemple :

1. Organisations autonomes décentralisées (DAOs), enchères on-chain et autres applications avec un état secret interne arbitraire.
2. Véritable configuration de confiance universelle : quelqu'un peut créer un programme obfusqué contenant une clé et exécuter n'importe quel programme en fournissant une sortie, en insérant hash(key, program) comme entrée. Avec un tel programme, n'importe qui peut insérer le programme 3 dans lui-même, combinant la clé préalable du programme et sa propre clé, pour étendre la configuration. Cela peut être utilisé pour générer une configuration de confiance 1-of-N pour n'importe quel protocole.
3. Vérification des ZK-SNARKs avec une seule signature : cela se fait simplement en configurant un environnement de confiance pour qu'une personne crée un programme obfusqué qui ne signe un message avec la clé que si le ZK-SNARK est valide.
4. Mempool chiffré : les transactions chiffrées deviennent très simples, de sorte qu'elles ne peuvent être déchiffrées qu'après un certain événement on-chain futur. Cela peut même inclure l'exécution réussie d'une VDF vérifiable.

Avec les signatures à usage unique, nous pouvons protéger la blockchain contre les attaques de réorganisation finale à 51 %, bien que les attaques de censure restent possibles. Des primitives similaires permettent la monnaie quantique, résolvant le problème de la double dépense sans blockchain, bien que de nombreuses applications plus complexes nécessitent encore une chaîne.

Si ces primitives deviennent suffisamment efficaces, la plupart des applications du monde pourraient être décentralisées. Le principal goulot d'étranglement sera la vérification de la correction de l'implémentation.

Voici quelques liens vers des recherches existantes :

• Protocole d'obfuscation indiscernable (2021): 
• Comment l'obfuscation peut aider Ethereum: 
• Première construction connue de signature à usage unique: 
• Tentative d'implémentation de l'obfuscation (1): 
• Tentative d'implémentation de l'obfuscation (2): 

Quels sont les travaux restants et les compromis ?

Il reste beaucoup de travail à faire, l'obfuscation indiscernable est encore très immature, et les constructions candidates sont d'une lenteur extrême (voire pire), les rendant inutilisables en pratique. L'obfuscation indiscernable est réputée pour être en temps polynomial « en théorie », mais en pratique, le temps d'exécution peut dépasser la durée de vie de l'univers. Les protocoles récents ont amélioré le temps d'exécution, mais la surcharge reste trop élevée pour une utilisation courante : un implémenteur estime le temps d'exécution à un an.

Les ordinateurs quantiques n'existent même pas encore : toutes les constructions que vous voyez sur Internet sont soit des prototypes incapables de traiter plus de 4 bits, soit ne sont pas de véritables ordinateurs quantiques, bien qu'ils puissent avoir des parties quantiques, mais ne peuvent pas exécuter des calculs significatifs comme les algorithmes de Shor ou de Grover. Récemment, il y a des signes que les « vrais » ordinateurs quantiques ne sont pas si loin. Cependant, même si de « vrais » ordinateurs quantiques apparaissent bientôt, il faudra probablement des décennies avant que les gens ordinaires puissent les utiliser sur leur ordinateur portable ou leur téléphone, et avant que les grandes institutions puissent casser la cryptographie à courbe elliptique.

Pour l'obfuscation indiscernable, un compromis clé concerne les hypothèses de sécurité, avec des conceptions plus agressives utilisant des hypothèses spéciales. Ces conceptions ont généralement des temps d'exécution plus réalistes, mais les hypothèses spéciales sont parfois invalidées. Avec le temps, nous pourrions mieux comprendre les réseaux et proposer des hypothèses plus robustes. Cependant, cette voie est plus risquée. L'approche plus conservatrice consiste à s'en tenir aux protocoles dont la sécurité peut être prouvée par réduction à des hypothèses « standard », mais cela pourrait signifier attendre plus longtemps pour obtenir des protocoles suffisamment rapides.

Comment cela interagit-il avec les autres parties de la feuille de route ?

Une cryptographie extrêmement puissante pourrait bouleverser la donne, par exemple :

1. Si la vérification des ZK-SNARKs devient aussi simple qu'une signature, nous n'aurons peut-être plus besoin de protocoles d'agrégation ; nous pourrons vérifier directement sur la chaîne.
2. Les signatures à usage unique pourraient signifier des protocoles de preuve d'enjeu plus sûrs.
3. De nombreux protocoles de confidentialité complexes pourraient être remplacés par une seule EVM privée.
4. Les mempools chiffrés deviendraient plus faciles à mettre en œuvre.

Au début, les avantages apparaîtront au niveau de l'application, car le L1 d'Ethereum doit rester conservateur en matière d'hypothèses de sécurité. Cependant, même une utilisation au niveau de l'application pourrait être révolutionnaire, comme ce fut le cas avec l'arrivée des ZK-SNARKs.