Nouvel article de Vitaliks : L'avenir possible d'Ethereum, The Splurge

Titre original : Futurs possibles du protocole Ethereum, partie 6 : Le Splurge

Article original de @VitalikButerin

Traduction originale : zhouzhou, BlockBeats

Voici le contenu original (pour une lecture et une compréhension plus faciles, le contenu original a été réorganisé) :

Certaines choses sont difficiles à classer dans une seule catégorie, et dans la conception du protocole Ethereum, de nombreux détails sont très importants pour le succès d'Ethereum. En fait, environ la moitié du contenu concerne différents types d'améliorations EVM, et le reste est constitué de divers sujets de niche. C'est ce que signifie s'épanouir.

Feuille de route 2023 : prospérité

La prospérité : un objectif clé

Amener l'EVM à un état final performant et stable

Introduire l'abstraction de compte dans le protocole, permettant à tous les utilisateurs de profiter de comptes plus sûrs et plus pratiques

Optimiser les coûts de transaction, augmenter l'évolutivité tout en réduisant les risques

Exploration avancée cryptoLa graphie pour améliorer considérablement Ethereum à long terme

Dans ce chapitre

Améliorations de l'EVM

Abstraction de compte

Améliorations de la norme EIP-1559

VDF (Fonction de retard vérifiable)

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

Améliorations de l'EVM

Quel problème a été résolu ?

L'EVM actuel est difficile à analyser statiquement, ce qui rend difficile la création d'implémentations efficaces, la vérification formelle du code et la réalisation d'extensions supplémentaires. De plus, l'EVM est inefficace et il est difficile d'implémenter de nombreuses formes de cryptographie avancée à moins qu'elles ne soient explicitement prises en charge par la précompilation.

Qu'est-ce que c'est et comment ça marche ?

La première étape de la feuille de route actuelle d'amélioration d'EVM est le format d'objet EVM (EOF), dont l'inclusion est prévue dans le prochain hard fork. EOF est une série d'EIP qui spécifie une nouvelle version de code EVM avec un certain nombre de fonctionnalités uniques, plus particulièrement :

• Séparation entre le code (qui peut être exécuté mais ne peut pas être lu depuis l'EVM) et les données (qui peuvent être lues mais ne peuvent pas être exécutées)

• Les sauts dynamiques sont interdits, seuls les sauts statiques sont autorisés

• Le code EVM ne peut plus observer les informations relatives au carburant

• Ajout d'un nouveau mécanisme de sous-routine explicite

Structure du code EOF

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

Les contrats à l'ancienne continueront d'exister et pourront être créés, même s'ils finiront probablement par être supprimés (peut-être même obligés de passer au code EOF). Les contrats de nouveau type bénéficieront des gains d'efficacité apportés par l'EOF - d'abord sous la forme d'un bytecode légèrement plus petit via la fonction de sous-routine, puis sous la forme de nouvelles fonctionnalités spécifiques à l'EOF ou de coûts de gaz réduits.

Après l'introduction de l'EOF, d'autres mises à niveau sont devenues plus faciles, et la plus développée à l'heure actuelle est l'extension arithmétique modulaire EVM (EVM-MAX) . EVM-MAX crée un nouvel ensemble d'opérations spécifiquement pour les opérations modulaires et les place dans un nouvel espace mémoire qui n'est pas accessible par d'autres opcodes, ce qui permet d'utiliser des optimisations telles que Multiplication de Montgomery .

Une idée plus récente consiste à combiner EVM-MAX avec la fonctionnalité Single Instruction Multiple Data (SIMD). SIMD existe depuis longtemps en tant que concept Ethereum, proposé pour la première fois par Greg Colvins EIP-616 . SIMD peut être utilisé pour accélérer de nombreuses formes de cryptographie, notamment les fonctions de hachage, les STARK 32 bits et la cryptographie basée sur un réseau. La combinaison d'EVM-MAX et de SIMD fait de ces deux extensions orientées performances une association naturelle.

Une conception approximative pour un EIP combiné commencerait par EIP-6690, puis :

• Autorise (i) tout nombre impair ou (ii) toute puissance de 2 jusqu'à 2768 comme module

• Pour chaque opcode EVM-MAX (addition, soustraction, multiplication), ajoutez une version qui utilise 7 immédiats au lieu de 3 x, y, z : x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Dans le code Python, ces opcodes fonctionnent comme ceci :

• pour i dans la plage (compte) :
  mem[z_start + z_skip * count] = op(
  mémoire[x_start + x_skip * nombre],
  mémoire[y_start + y_skip * count]
  )

Dans la mise en œuvre concrète, ces tâches seront traitées en parallèle.

• Il est possible d'ajouter XOR, AND, OR, NOT et SHIFT (bouclant et non bouclant), au moins pour les modules de puissances de 2. Il est également possible d'ajouter ISZERO (en envoyant la sortie vers la pile principale EVM), qui sera suffisamment puissant pour implémenter la cryptographie à courbe elliptique, la cryptographie à petit domaine (comme Poseidon, Circle STARKs), les fonctions de hachage traditionnelles (comme SHA 256, KECCAK, BLAKE) et la cryptographie basée sur un réseau. D'autres mises à niveau d'EVM sont également possibles, mais ont reçu moins d'attention jusqu'à présent.

Liens vers des recherches existantes

Fin du Festival: https://evmobjectformat.org/

EVM-MAX: https://eips.ethereum.org/EIPS/eip-6690

SIMD: https://eips.ethereum.org/EIPS/eip-616

Travail restant à accomplir et compromis

Actuellement, EOF est prévu pour être inclus dans le prochain hard fork. Bien qu'il soit toujours possible de le supprimer à la dernière minute (des fonctionnalités ont été temporairement supprimées dans les hard forks précédents), cela serait très difficile. La suppression d'EOF signifie que toutes les futures mises à niveau de l'EVM devront être effectuées sans EOF, ce qui est possible mais peut être plus difficile.

Le principal compromis de l'EVM est la complexité de L1 par rapport à la complexité de l'infrastructure. EOF représente une grande quantité de code qui doit être ajoutée à l'implémentation EVM, et la vérification du code statique est relativement complexe. Cependant, en échange, nous pouvons simplifier le langage de haut niveau, simplifier l'implémentation EVM et bénéficier d'autres avantages. On peut dire que la feuille de route qui donne la priorité à l'amélioration continue d'Ethereum L1 devrait inclure et s'appuyer sur EOF.

Un travail important qui doit être fait est de mettre en œuvre quelque chose comme EVM-MAX plus la fonctionnalité SIMD et d'évaluer la consommation de gaz de diverses opérations de cryptographie.

Comment interagit-il avec le reste de la feuille de route ?

L1 ajuste son EVM afin que L2 puisse s'adapter en conséquence plus facilement. Si les deux ne sont pas ajustés de manière synchrone, cela peut entraîner une incompatibilité et des effets indésirables. De plus, EVM-MAX et SIMD peuvent réduire le coût en gaz de nombreux systèmes de preuve, ce qui rend L2 plus efficace. Cela facilite également le remplacement d'un plus grand nombre de précompilations par du code EVM capable d'effectuer les mêmes tâches, éventuellement sans affecter considérablement l'efficacité.

Abstraction de compte

Quel problème a été résolu ?

Actuellement, les transactions ne peuvent être vérifiées que d'une seule manière : les signatures ECDSA. Dans un premier temps, l'abstraction de compte vise à aller au-delà de cela, en permettant à la logique de vérification d'un compte d'être un code EVM arbitraire. Cela peut permettre une gamme d'applications :

• Passer à la cryptographie résistante aux quantiques

• Faire tourner les anciennes clés (largement) considéré comme une pratique de sécurité recommandée )

• Portefeuilles multi-signatures et portefeuilles de récupération sociale

• Utilisez une clé pour les opérations de faible valeur et une autre clé (ou un ensemble de clés) pour les opérations de grande valeur

Permet aux protocoles de confidentialité de fonctionner sans relais, réduisant considérablement leur complexité et supprimant un point central de dépendance clé

Depuis que l'abstraction des comptes a été proposée en 2015, ses objectifs se sont également élargis pour inclure un grand nombre d'objectifs de commodité, comme un compte qui n'a pas d'ETH mais qui a de l'ERC 20 et qui peut payer le gaz avec l'ERC 20. Voici un tableau récapitulatif de ces objectifs :

MPC (Multi-Party Computation) est un Une technologie vieille de 40 ans pour diviser une clé en plusieurs parties et les stocker sur plusieurs appareils, en utilisant des techniques cryptographiques pour générer des signatures sans combiner directement ces parties de clé.

EIP-7702 est une proposition qui devrait être introduite dans le prochain hard fork. L'EIP-7702 est le résultat d'une prise de conscience croissante de la nécessité de fournir une commodité d'abstraction de compte au bénéfice de tous les utilisateurs (y compris les utilisateurs EOA). Elle vise à améliorer l'expérience de tous les utilisateurs à court terme et à éviter la scission en deux écosystèmes.

Le travail a commencé avec EIP-3074 et a finalement formé EIP-7702. EIP-7702 fournit les fonctionnalités pratiques d'abstraction de compte à tous les utilisateurs, y compris les EOA actuels (comptes détenus en externe, c'est-à-dire les comptes contrôlés par des signatures ECDSA).

Comme vous pouvez le voir sur le graphique, même si certains défis (notamment celui de la commodité) peuvent être résolus grâce à des techniques progressives telles que le calcul multipartite ou l'EIP-7702, l'objectif de sécurité principal de la proposition d'abstraction de compte d'origine ne peut être atteint qu'en faisant marche arrière et en résolvant le problème d'origine : permettre au code de contrat intelligent de contrôler la vérification des transactions. La raison pour laquelle cela n'a pas été réalisé jusqu'à présent est qu'il est difficile de le mettre en œuvre de manière sécurisée.

Qu'est-ce que c'est et comment ça marche ?

Le cœur de l'abstraction des comptes est simple : permettre aux contrats intelligents d'initier des transactions, et pas seulement des EOA. Toute la complexité vient de la mise en œuvre de cette approche de manière à ce qu'elle soit compatible avec le maintien d'un réseau décentralisé et la protection contre les attaques par déni de service.

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

S'il existe 1 000 comptes dont les fonctions de validation reposent toutes sur une seule valeur S et que la valeur actuelle de S valide toutes les transactions du pool de mémoire, une seule transaction qui inverse la valeur de S peut invalider toutes les autres transactions du pool de mémoire. Cela permet aux attaquants d'envoyer des transactions indésirables au pool de mémoire à un coût très faible, encombrant ainsi les ressources des nœuds du réseau.

Après des années de travail acharné visant à étendre les fonctionnalités tout en limitant les risques de déni de service (DoS), une solution pour obtenir une abstraction de compte idéale a finalement été trouvée : ERC-4337.

La norme ERC-4337 fonctionne en divisant le traitement des actions utilisateur en deux phases : vérification et exécution. Toutes les vérifications sont traitées en premier, puis toutes les exécutions. Dans le pool de mémoire, les actions utilisateur ne sont acceptées que si la phase de vérification n'implique que leur propre compte et ne lit pas les variables d'environnement. Cela permet d'éviter les attaques par invalidation multiple. De plus, des limites strictes de gaz sont également appliquées à l'étape de vérification.

L'ERC-4337 a été conçu comme une norme de protocole supplémentaire (ERC) car à l'époque, les développeurs de clients Ethereum se concentraient sur la fusion (Merge) et n'avaient pas d'énergie supplémentaire pour gérer d'autres fonctionnalités. C'est pourquoi l'ERC-4337 utilise des objets appelés actions utilisateur au lieu de transactions classiques. Cependant, nous avons récemment réalisé que nous devions en écrire au moins certaines dans le protocole.

Il y a deux raisons principales à cela :

1. Inefficacité inhérente à EntryPoint en tant que contrat : il y a une surcharge fixe d'environ 100 000 gaz par paquet et des milliers de gaz supplémentaires par opération utilisateur.

2. Nécessité de garantir les propriétés d'Ethereum : les garanties d'inclusion créées par les listes d'inclusion doivent être transférées aux utilisateurs d'abstraction de compte.

De plus, ERC-4337 étend également deux fonctions :

• Paymasters : une fonctionnalité qui permet à un compte de payer des frais au nom d'un autre compte. Cela viole la règle selon laquelle seul le compte de l'expéditeur lui-même est accessible pendant la phase de vérification. Un traitement spécial est donc introduit pour garantir la sécurité du mécanisme de paiement principal.

• Agrégateurs : fonctions qui prennent en charge l'agrégation de signatures, comme l'agrégation BLS ou l'agrégation basée sur SNARK. Cela est nécessaire pour obtenir la plus grande efficacité des données sur Rollup.

Liens vers des recherches existantes

Une conférence sur l'histoire de l'abstraction comptable : https://www.youtube.com/watch?v=iLf8qpOmxQc

ERC-4337: https://eips.ethereum.org/EIPS/eip-4337

EIP-7702: https://eips.ethereum.org/EIPS/eip-7702

Code BLSWallet (utilisant la fonction d'agrégation) : https://github.com/getwax/bls-wallet

EIP-7562 (Abstraction de compte écrite dans le protocole) : https://eips.ethereum.org/EIPS/eip-7562

EIP-7701 (abstraction de compte de protocole d'écriture basée sur EOF) : https://eips.ethereum.org/EIPS/eip-7701

Travail restant à accomplir et compromis

La principale question à résoudre est de savoir comment introduire pleinement l'abstraction de compte dans le protocole. L'EIP le plus populaire pour écrire l'abstraction de compte de protocole est EIP-7701 , qui implémente l'abstraction de compte sur EOF. Un compte peut avoir une section de code distincte pour la vérification. Si le compte définit cette section de code, le code sera exécuté à l'étape de vérification des transactions du compte.

La beauté de cette approche est qu’elle montre clairement deux vues équivalentes de l’abstraction des comptes locaux :

1. Intégrer EIP-4337 au protocole

2. Un nouveau type d'EOA où l'algorithme de signature est l'exécution de code EVM

Si nous commençons par des limites strictes sur la complexité du code qui peut être exécuté pendant la vérification (aucun accès à l'état externe autorisé, et même la limite de gaz initiale définie comme étant suffisamment basse pour être inefficace pour les applications résistantes aux quantiques ou préservant la confidentialité), alors la sécurité de cette approche est claire : il suffit de remplacer la vérification ECDSA par l'exécution du code EVM qui prend un temps similaire.

Cependant, au fil du temps, nous devrons assouplir ces limites, car il est très important de permettre aux applications préservant la confidentialité de fonctionner sans relais, ainsi que de résister aux attaques quantiques. Pour ce faire, nous devons trouver des moyens de gérer de manière plus flexible les risques de déni de service (DoS) sans exiger que l'étape de vérification soit extrêmement minimaliste.

Le principal compromis semble être d’écrire rapidement une solution qui plaira à moins de personnes plutôt que d’attendre plus longtemps pour une solution potentiellement plus idéale, l’approche idéale étant probablement une sorte d’hybride. Une approche hybride consisterait à écrire certains cas d’utilisation plus rapidement et à laisser plus de temps pour explorer d’autres cas d’utilisation. Une autre approche consisterait à déployer d’abord une version plus ambitieuse de l’abstraction de compte sur L2. Cependant, le défi ici est que les équipes L2 doivent être sûres que la proposition d’adoption fonctionnera avant d’être prêtes à la mettre en œuvre, en particulier pour garantir que L1 et/ou d’autres L2 puissent adopter des solutions compatibles à l’avenir.

Une autre application que nous devons considérer explicitement est comptes de stockage de clés qui stocke l'état lié au compte sur L1 ou sur un L2 dédié, mais peut être utilisé sur L1 et sur tout L2 compatible. Pour ce faire efficacement, L2 peut nécessiter de prendre en charge des opcodes tels que CHARGE L1S ou APPEL À DISTANCE ÉLECTRONIQUE , mais cela nécessitera également l'implémentation de l'abstraction de compte sur L2 pour prendre en charge ces opérations.

Comment interagit-il avec le reste de la feuille de route ?

Les listes d'inclusion doivent prendre en charge les transactions d'abstraction de compte et, dans la pratique, les exigences pour les listes d'inclusion sont en fait très similaires à celles des pools de mémoire décentralisés, bien qu'il y ait un peu plus de flexibilité pour les listes d'inclusion. De plus, les implémentations d'abstraction de compte doivent être coordonnées entre L1 et L2 autant que possible. Si à l'avenir nous prévoyons que la plupart des utilisateurs utiliseront des cumuls de stockage de clés, la conception de l'abstraction de compte devra être basée sur cela.

Améliorations de la norme EIP-1559

Quel problème 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, le courant mise en œuvre de EIP-1559 n'est pas parfait sous plusieurs aspects :

1. La formule est légèrement erronée : elle ne vise pas 50% de blocs, mais plutôt environ 50-53% de blocs complets, en fonction de la variance (cela a à voir avec ce que les mathématiciens appellent « l'inégalité moyenne arithmético-géométrique »).

2. Ne pas s’adapter assez rapidement aux situations extrêmes.

La dernière formule pour les blobs (EIP-4844) est spécifiquement conçue pour résoudre le premier problème et est également plus propre dans l'ensemble. Cependant, ni l'EIP-1559 ni l'EIP-4844 ne tentent de résoudre le deuxième problème. En conséquence, le statu quo est un compromis confus impliquant deux mécanismes différents et certains soutiennent que les deux devront être améliorés au fil du temps.

En outre, il existe d’autres faiblesses dans la tarification des ressources d’Ethereum qui ne sont pas liées à l’EIP-1559, mais qui peuvent être résolues par des ajustements à l’EIP-1559. L’un des principaux problèmes est la différence entre le scénario moyen et le pire des cas : les prix des ressources dans Ethereum doivent être fixés pour gérer le pire des cas, où la consommation totale de gaz d’un bloc occupe une ressource, mais l’utilisation moyenne réelle est bien inférieure à cela, ce qui entraîne des inefficacités.

Qu’est-ce que le gaz multidimensionnel et comment fonctionne-t-il ?

La solution à ces inefficacités est gaz multidimensionnel : 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, l'empaquetage optimal d'un bloc avec plusieurs contraintes de ressources est une tâche difficile. problème complexe du sac à dos multidimensionnel Avec EIP-1559, la plupart des blocs n'atteindront pas leur pleine capacité sur aucune ressource, donc un algorithme simple comme accepter toute transaction qui paie suffisamment de frais est suffisant.

Actuellement, nous disposons de gaz multidimensionnels pour l'exécution et les blocs de données ; en principe, nous pouvons étendre cela à davantage de dimensions : telles que les données d'appel (données de transaction), la lecture/écriture d'état et l'extension de la taille de l'état.

EIP-7706 introduit une nouvelle dimension de gaz spécifiquement pour les données d'appel. Il simplifie également le mécanisme de gaz multidimensionnel en unifiant les trois types de gaz dans un cadre unique (de type EIP-4844), résolvant ainsi également les défauts mathématiques de l'EIP-1559. EIP-7623 est une solution plus précise au problème des ressources du cas moyen et du pire des cas, avec une limite plus stricte sur les données d'appel maximales sans introduire une toute nouvelle dimension.

Une autre direction de recherche consiste à résoudre le problème du taux de mise à jour et à trouver un algorithme de calcul des frais de base plus rapide tout en préservant les invariants clés introduits par le mécanisme EIP-4844 (c'est-à-dire qu'à long terme, l'utilisation moyenne est juste proche de la valeur cible).

Liens vers des recherches existantes

FAQ sur la norme EIP-1559 : FAQ sur la norme EIP-1559

Empirique analyse de l'EIP-1559

Proposé améliorations pour permettre des ajustements rapides :

FAQ EIP-4844 sur le mécanisme des frais de base : FAQ sur la norme EIP-4844

EIP-7706: EIP-7706

EIP-7623: EIP-7623

Gaz multidimensionnel : Gaz multidimensionnel

Quelles sont les tâches et les compromis restants ?

Il existe deux principaux compromis pour le gaz multidimensionnel :

1. Augmenter la complexité du protocole : l’introduction du gaz multidimensionnel rendra le protocole plus complexe.

2. Complexité accrue de l’algorithme optimal requis pour remplir les blocs : L’algorithme optimal pour remplir les blocs jusqu’à leur capacité deviendra également plus complexe.

La complexité du protocole est relativement faible pour les données d'appel, mais pour les dimensions de gaz internes à l'EVM (telles que les lectures et écritures de stockage), la complexité augmente. Le problème est que non seulement les utilisateurs définissent des limites de gaz, mais les contrats définissent également des limites lors de l'appel d'autres contrats. Et actuellement, la seule façon de définir des limites est dans une seule dimension.

Une solution simple consiste à rendre le gaz multidimensionnel disponible uniquement dans EOF, car EOF ne permet pas aux contrats de définir des limites de gaz lors de l'appel d'autres contrats. Les contrats non EOF doivent payer pour tous les types de gaz lors de l'exécution d'opérations de stockage (par exemple, si SLOAD occupe 0,03% de la limite de gaz d'accès au stockage en bloc, les utilisateurs non EOF seront également facturés 0,03% de la limite de gaz d'exécution).

Des recherches plus poussées sur le gaz multidimensionnel aideront à comprendre ces compromis et à trouver l’équilibre idéal.

Comment interagit-il avec le reste de la feuille de route ?

La mise en œuvre réussie de Gas multidimensionnel peut réduire considérablement l'utilisation des ressources dans les cas les plus défavorables, réduisant ainsi la pression pour optimiser les performances afin de répondre à des exigences telles que les arbres binaires basés sur des hachages STARK. La définition d'un objectif clair pour la croissance de la taille de l'état permettra aux développeurs clients de planifier et d'estimer plus facilement les besoins à l'avenir.

Comme mentionné précédemment, l’existence de l’EOF facilite la mise en œuvre de versions plus extrêmes du gaz multidimensionnel en raison de sa nature inobservable.

Fonctions de retard vérifiables (VDF)

Quel problème cela résout-il ?

Actuellement, Ethereum utilise le caractère aléatoire basé sur RANDAO pour sélectionner les proposants. Le caractère aléatoire de RANDAO fonctionne en exigeant que chaque proposant révèle un secret auquel il s'est engagé à l'avance, et en mélangeant chaque secret révélé dans le caractère aléatoire.

Chaque proposant a donc un peu de pouvoir : il peut modifier le caractère aléatoire en ne se présentant pas (à un coût). Cela a du sens pour trouver des proposants, car il est très rare que vous abandonniez une opportunité pour en obtenir deux nouveaux. Mais ce n'est pas idéal pour les applications on-chain qui ont besoin de caractère aléatoire. Idéalement, nous devrions trouver une source de caractère aléatoire plus robuste.

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

Une fonction de retard vérifiable est une fonction qui ne peut être calculée que de manière séquentielle et ne peut pas être accélérée par parallélisation. Un exemple simple est le hachage répété : for i in range(10**9): x = hash(x). La sortie est prouvée correcte à l'aide de SNARK et peut être utilisée comme valeur aléatoire.

L'idée est que les entrées sont choisies en fonction des informations disponibles à l'instant T, tandis que les sorties ne sont pas encore connues à l'instant T : les sorties ne sont disponibles qu'après T, une fois que quelqu'un a entièrement exécuté le calcul. Comme n'importe qui peut exécuter le calcul, il n'y a aucune possibilité de dissimuler les résultats, et donc aucune possibilité de les manipuler.

Le principal risque avec les fonctions de retard vérifiables est l’optimisation accidentelle : quelqu’un trouve un moyen d’exécuter la fonction plus rapidement que prévu, manipulant ainsi les informations qu’elle révèle à l’instant T.

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

1. Accélération matérielle : quelqu'un crée un ASIC qui exécute des cycles de calcul plus rapidement que le matériel existant.

2. Parallélisation accidentelle : quelqu'un trouve un moyen d'exécuter une fonction plus rapidement en la parallélisant, même si cela nécessite 100 fois plus de ressources.

La création d'un VDF performant consiste à éviter ces deux problèmes tout en préservant l'efficacité (par exemple, l'un des problèmes des approches basées sur le hachage est que le SNARKing des hachages en temps réel nécessite du matériel lourd). L'accélération matérielle est généralement abordée par un acteur d'intérêt public qui crée et distribue lui-même un ASIC VDF quasi optimal.

Liens vers des recherches existantes

Site de recherche VDF : vdfresearch.org

Pensée sur les attaques sur VDF dans Ethereum, 2018 :

Attaques contre MinRoot

Quelles sont les tâches et les compromis restants ?

Actuellement, il n’existe pas de construction VDF unique qui réponde pleinement à toutes les exigences des chercheurs d’Ethereum. Des travaux supplémentaires sont nécessaires pour trouver une telle fonction. Si elle est trouvée, le principal compromis est de savoir s’il faut l’inclure : un simple compromis entre la fonctionnalité et la complexité du protocole et les risques de sécurité.

Si nous pensons qu'un VDF est sécurisé, mais qu'il s'avère qu'il ne l'est pas, alors, selon la manière dont il est implémenté, la sécurité dégénérera jusqu'à l'hypothèse RANDAO (1 bit de contrôle par attaquant) ou légèrement pire. Par conséquent, même si le VDF échoue, il ne cassera pas le protocole, mais il cassera les applications ou toute nouvelle fonctionnalité du protocole qui en dépend fortement.

Comment interagit-il avec le reste de la feuille de route ?

Les VDF sont un composant relativement autonome du protocole Ethereum qui, en plus d'augmenter la sécurité de la sélection des proposants, a des applications dans (i) les applications en chaîne qui reposent sur le caractère aléatoire et (ii) les mempools cryptographiques, bien que la création de mempools cryptographiques basés sur les VDF repose toujours sur des découvertes cryptographiques supplémentaires qui n'ont pas encore eu lieu.

Il est important de garder à l'esprit que, compte tenu de l'incertitude liée au matériel, il existe une certaine marge entre le moment où la sortie VDF est produite et celui où elle est nécessaire. Cela signifie que les informations seront disponibles plusieurs blocs plus tôt. Cela peut être un coût acceptable, mais il doit être pris en compte dans les conceptions de finalisation à un seul emplacement ou de sélection de comité.

Obfuscation et signatures à usage unique : le futur lointain de la cryptographie

Quel problème cela résout-il ?

L'un des articles les plus célèbres de Nick Szabo est son article de 1997 sur le « Protocole de Dieu ». Dans cet article, il note que de nombreuses applications multipartites s'appuient 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é qui effectue le même travail sans nécessiter réellement la confiance d'un participant particulier.

Jusqu’à présent, nous n’avons atteint que partiellement cet idéal. Si tout ce que nous voulons, c’est un ordinateur virtuel transparent dont les données et les calculs ne peuvent pas ê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 qu’avec une évolutivité limitée.

Si la confidentialité est l'objectif, jusqu'à récemment, nous n'avons pu développer que quelques protocoles spécifiques pour des applications spécifiques : signatures numériques pour l'authentification de base, signatures en anneau et signatures en anneau pouvant être liées pour l'anonymat brut, cryptage basé sur l'identité pour un cryptage plus pratique sous certaines hypothèses sur les émetteurs de confiance, signatures aveugles pour l'argent électronique de type Charm, etc. Cette approche nécessite beaucoup de travail pour chaque nouvelle application.

Dans les années 2010, nous avons eu un premier aperçu d’une approche différente et plus puissante, basée sur la cryptographie programmable. Plutôt que de créer un nouveau protocole pour chaque nouvelle application, nous pouvons utiliser de nouveaux protocoles puissants, en particulier les ZK-SNARK, pour ajouter des garanties cryptographiques à des programmes arbitraires.

Les ZK-SNARK permettent aux utilisateurs de prouver des déclarations arbitraires sur les données qu'ils détiennent, et les preuves sont (i) facilement vérifiables, et (ii) ne révèlent aucune donnée autre que la déclaration elle-même. Il s'agit d'un énorme pas en avant en matière de confidentialité et d'évolutivité, et je le compare à l'impact des transformateurs dans l'IA. Des milliers d'années-homme de travail spécifique à une application ont été soudainement remplacées par cette solution générale qui peut gérer une gamme de problèmes étonnamment large.

Cependant, les ZK-SNARK ne sont que la première de trois primitives générales similaires extrêmement puissantes. Ces protocoles sont si puissants que lorsque j'y pense, ils me rappellent un ensemble de cartes extrêmement puissantes de Yu-Gi-Oh ! — le jeu de cartes et l'émission télévisée auxquels je jouais quand j'étais enfant : les cartes des dieux égyptiens.

Les cartes des dieux égyptiens sont trois cartes extrêmement puissantes. La légende raconte que le processus de création de ces cartes peut être fatal et que leur puissance rend leur utilisation interdite dans les duels. De même, en cryptographie, nous avons également cet ensemble de trois protocoles des dieux égyptiens :

Que sont les ZK-SNARK et comment fonctionnent-ils ?

ZK-SNARKs est l'un des trois protocoles dont nous disposons déjà, avec un niveau de maturité élevé. Au cours des cinq dernières années, les améliorations spectaculaires apportées à la vitesse de démonstration et à la convivialité des développeurs ont fait de ZK-SNARKs une pierre angulaire de la stratégie d'évolutivité et de confidentialité d'Ethereums. Mais les ZK-SNARKs ont une limitation importante : vous devez connaître les données pour les prouver. Chaque état d'une application ZK-SNARK doit avoir un propriétaire unique qui doit être présent pour approuver la lecture ou l'écriture de cet état.

Le deuxième protocole qui ne présente pas cette limitation est le chiffrement entièrement homomorphe (FHE), qui vous permet d'effectuer n'importe quel calcul sur des données chiffrées sans jamais consulter les données. Cela vous permet d'effectuer des calculs sur les données des utilisateurs pour leur bénéfice tout en préservant la confidentialité des données et de l'algorithme.

Il permet également de faire évoluer des systèmes de vote comme MACI pour obtenir des garanties de sécurité et de confidentialité presque parfaites. Le FHE a longtemps été considéré comme trop inefficace pour une utilisation pratique, mais il devient désormais suffisamment efficace pour commencer à voir des applications dans le monde réel.

Cursive est une application qui exploite le calcul à deux parties et le cryptage entièrement homomorphe (FHE) pour la découverte d'intérêts communs préservant la confidentialité.

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

Vient ensuite le troisième protocole, encore plus puissant que les deux premiers combinés : l'obfuscation par indistinguabilité. Bien que cette technologie soit encore loin d'être mature, nous disposons en 2020 de protocoles théoriquement valables basés sur des hypothèses de sécurité standard, et nous avons récemment commencé à les mettre en œuvre.

L'obscurcissement indiscernable vous permet de créer un programme cryptographique qui effectue des calculs arbitraires tout en masquant tous les détails internes du programme. À titre d'exemple simple, vous pouvez placer votre clé privée dans un programme obscurci qui vous permet uniquement de l'utiliser pour signer des nombres premiers, et distribuer ce programme à d'autres. Ils peuvent utiliser ce programme pour signer n'importe quel nombre premier, mais ils ne pourront pas extraire la clé. Cependant, ses capacités vont bien au-delà : combinées au hachage, elles peuvent être utilisées pour implémenter n'importe quelle autre primitive cryptographique, et bien plus encore.

La seule chose qu'un programme indiscernable ne peut pas faire, c'est empêcher sa copie. Mais pour cela, il existe une technologie plus puissante qui se profile à l'horizon, même si elle nécessite que tout le monde soit équipé d'un ordinateur quantique : les signatures quantiques à un seul coup.

En combinant l'obfuscation et les signatures à usage unique, nous pouvons créer un tiers presque parfait et sans confiance. Le seul objectif qui ne peut être atteint par la cryptographie seule et qui doit encore être garanti par la blockchain est la résistance à la censure. Ces technologies peuvent non seulement rendre Ethereum lui-même plus sûr, mais aussi créer des applications plus puissantes sur celui-ci.

Pour mieux comprendre comment ces primitives ajoutent des capacités supplémentaires, prenons le vote comme exemple clé. Le vote est un problème intéressant car il doit satisfaire à de nombreuses propriétés de sécurité complexes, notamment une vérifiabilité et une confidentialité très fortes. Bien que des protocoles de vote dotés de propriétés de sécurité solides existent depuis des décennies, nous pouvons nous compliquer la tâche en exigeant des conceptions capables de gérer des protocoles de vote arbitraires : vote quadratique, financement quadratique restreint par paires, financement quadratique correspondant à des clusters, etc. En d'autres termes, nous voulons que l'étape de comptage des votes soit un programme arbitraire.

Tout d'abord, supposons que nous publions les résultats du vote sur la blockchain. Cela nous donne une vérifiabilité publique (n'importe qui peut vérifier que le résultat final est correct, y compris les règles de décompte et d'éligibilité) et une résistance à la censure (on ne peut pas empêcher les gens de voter). Mais nous n'avons pas de vie privée.

Nous avons ensuite ajouté les ZK-SNARK, et nous avons désormais la confidentialité : chaque vote est anonyme, tout en garantissant que seuls les électeurs autorisés peuvent voter, et que chaque électeur ne peut voter qu'une seule fois.

Ensuite, nous avons introduit le mécanisme MACI, où les votes sont chiffrés avec une clé de déchiffrement sur un serveur central. Le serveur central est responsable du processus de décompte des votes, y compris la suppression des votes en double et la publication d'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 également une garantie de résistance à la coercition : les utilisateurs ne peuvent pas prouver pour quel vote ils ont voté, même s'ils le voulaient. En effet, si les utilisateurs peuvent prouver leur vote, ils ne peuvent pas prouver qu'ils n'ont pas voté pour contrebalancer ce vote. Cela empêche la corruption et d'autres attaques.

Nous exécutons le décompte des votes dans FHE, puis effectuons le calcul du décryptage du seuil N/2 sur N. Cela améliore la garantie anti-coercition à N/2 sur N au lieu de 1 sur 1.

Nous obscurcissons le programme de comptage et le concevons de manière à ce qu'il ne puisse produire des résultats que lorsqu'il est autorisé, ce qui peut être une preuve de consensus de blockchain, une sorte de preuve de travail ou une combinaison des deux. Cela rend la garantie anti-coercition presque parfaite : dans le cas d'un consensus de blockchain, 51% de validateurs doivent s'entendre pour le briser ; dans le cas d'une preuve de travail, même si tout le monde s'entend, il sera extrêmement coûteux de recompter les votes avec un sous-ensemble différent d'électeurs pour essayer d'extraire le comportement d'un seul électeur. Nous pouvons même faire en sorte que le programme effectue de petits ajustements aléatoires au décompte final pour augmenter encore la difficulté d'extraire le comportement d'un seul électeur.

Nous avons ajouté des signatures à usage unique, une primitive qui s'appuie sur l'informatique quantique et qui permet à une signature d'être utilisée une seule fois pour un certain type d'information. Cela rend la garantie anti-coercition vraiment parfaite.

L'obfuscation indiscernable prend également en charge d'autres applications puissantes. Par exemple :

1. Organisations autonomes décentralisées (DAO), enchères en chaîne et autres applications avec des états secrets internes arbitraires.

2. Une configuration de confiance véritablement universelle : quelqu'un peut créer un programme obscurci contenant une clé, exécuter n'importe quel programme et fournir la sortie, en mettant hash(key, program) comme entrée dans le programme. Étant donné un tel programme, n'importe qui peut mettre le programme 3 en lui-même, en combinant la pré-clé du programme et sa propre clé, étendant ainsi la configuration. Cela peut être utilisé pour générer une configuration de confiance 1 sur N pour n'importe quel protocole.

3. La vérification des ZK-SNARK ne nécessite qu'une seule signature : la mise en œuvre est très simple : configurez un environnement de confiance et demandez à quelqu'un de créer un obfuscateur qui ne signera les messages avec la clé que s'il existe un ZK-SNARK valide.

4. Pool de mémoire chiffré : il est très simple de chiffrer les transactions afin qu'elles ne puissent être déchiffrées que si un événement sur la chaîne se produit à l'avenir. Cela peut même inclure une fonction de délai vérifiable (VDF) exécutée avec succès.

Grâce aux signatures à usage unique, nous pouvons rendre les blockchains immunisées contre les attaques 51% avec inversion de finalité, bien que les attaques de censure soient toujours possibles. Des primitives telles que les signatures à usage unique rendent possible 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 peuvent être rendues suffisamment efficaces, la plupart des applications mondiales pourront être décentralisées. Le principal obstacle sera la vérification de l'exactitude de l'implémentation.

Voici quelques liens vers des recherches existantes :

1. Indiscernabilité Obscurcissement (2021):

2. Comment l'obfuscation peut aider Ethereum

3. Première construction connue de signatures en un seul coup

4. Tentative de mise en œuvre de l'obfuscation (1)

5. Tentative de mise en œuvre de l'obfuscation (2)

Quel travail reste-t-il à accomplir et quels sont les compromis ?

Il reste encore beaucoup de travail à faire, et l'obfuscation indiscernable est encore très immature, avec des constructions candidates qui tournent aussi lentement (sinon plus) que prévu et qui sont inutilisables dans les applications. L'obfuscation indiscernable est connue pour être théoriquement polynomiale, mais en pratique, sa durée d'exécution peut être plus longue que la durée de vie de l'univers. Les protocoles récents ont quelque peu allégé ce temps d'exécution, mais la surcharge est encore trop élevée pour une utilisation de routine : un implémenteur estime une durée d'exécution d'un an.

Les ordinateurs quantiques n’existent pas encore : toutes les constructions que vous voyez sur Internet sont soit des prototypes qui ne peuvent pas effectuer plus de 4 bits d’opérations, soit ce ne sont pas des ordinateurs quantiques du tout, et même s’ils peuvent avoir des parties quantiques, ils ne peuvent pas effectuer de calculs significatifs comme les algorithmes de Shor ou de Grovers. Certains signes récents indiquent que les véritables ordinateurs quantiques ne sont pas loin. Cependant, même si de véritables ordinateurs quantiques apparaissent bientôt, il faudra peut-être des décennies aux gens ordinaires pour utiliser des ordinateurs quantiques sur leurs ordinateurs portables ou leurs téléphones, jusqu’au jour où de puissantes institutions pourront déchiffrer la cryptographie à courbe elliptique.

Pour obtenir une obfuscation indiscernable, un compromis clé réside dans les hypothèses de sécurité, et il existe des conceptions plus agressives qui utilisent des hypothèses spéciales. Ces conceptions ont souvent des temps d'exécution plus réalistes, mais les hypothèses spéciales peuvent parfois finir par être rompues. Au fil du temps, nous pouvons mieux comprendre les réseaux et proposer des hypothèses moins susceptibles d'être rompues. Cependant, cette voie est plus risquée. Une approche plus conservatrice consisterait à s'en tenir à des protocoles dont la sécurité se réduit de manière prouvable à des hypothèses standard, mais cela peut signifier qu'il faut plus de temps pour obtenir un protocole qui s'exécute suffisamment rapidement.

Comment interagit-il avec le reste de la feuille de route ?

Une cryptographie extrêmement forte pourrait révolutionner le jeu, par exemple :

1. Si nous parvenons à rendre les ZK-SNARK aussi faciles à vérifier que la signature, nous n'aurons peut-être plus besoin d'aucun protocole d'agrégation ; nous pourrons simplement effectuer la vérification directement sur la chaîne.

2. Les signatures uniques pourraient signifier des protocoles de preuve d’enjeu plus sécurisés.

3. De nombreux protocoles de confidentialité complexes peuvent simplement nécessiter une machine virtuelle Ethereum préservant la confidentialité (EVM) pour les remplacer.

4. Le pool de mémoire crypté devient plus facile à mettre en œuvre.

Dans un premier temps, les avantages apparaîtront au niveau de la couche applicative, car la couche L1 d'Ethereum doit par nature être conservatrice dans ses hypothèses de sécurité. Cependant, l'utilisation au niveau de la couche applicative seule pourrait être perturbatrice, comme ce fut le cas avec l'avènement des ZK-SNARK.

Lien d'origine

Cet article provient d'Internet : Nouvel article de Vitalik : L'avenir possible d'Ethereum, The Splurge

En lien : Grayscale sélectionne soigneusement 35 jetons : FDV minimum de 300 millions de dollars américains, plus adapté aux grands investisseurs

FrançaisOriginal | Odaily Planet Daily ( @OdailyChina ) Auteur | Fu Howe ( @vincent 31515173 ) En tant que l'un des ponts reliant le Web3 et la finance traditionnelle, les initiatives de Grayscales dans l'industrie de la cryptographie ont attiré beaucoup d'attention. Des produits de confiance initiaux de Bitcoin, Ethereum et de nombreux jetons bien connus au lancement de Bitcoin spot ETF et Ethereum spot ETF cette année, la contribution de Grayscales à l'industrie de la cryptographie est évidente pour tous. Récemment, Grayscale a répertorié 35 actifs cryptographiques qu'elle envisage d'ajouter à ses produits à l'avenir. À cette fin, Odaily Planet Daily a d'abord classé les 35 devises par piste, puis les a triées par la valeur marchande de chaque devise, et a partagé les tendances de prix des deux dernières années avec les lecteurs au moyen de diagrammes. Il y a un total de…