Vitalik: L’avenir possible du protocole Ethereum – la folie

Auteur: Vitalik, fondateur d’Ethereum;

Remarque: Cet article est la sixième partie de la série d’articles récemment publiés par Vitalik, fondateur d’Ethereum,Futures possibles du protocole Ethereum, partie 6: La folie», Voir la cinquième partie»Vitalik: L’avenir possible du protocole Ethereum – la purge», Voir la quatrième partie»Vitalik: L’avenir possible d’Ethereum le verge« . Voir « Vitalik: objectifs clés de l’ethereum la phase du fléau« , Voir la deuxième partie »Vitalik: Comment le protocole Ethereum devrait-il se développer au stade de surtension», Voir la première partie»Quoi d’autre peut être amélioré sur Ethereum pos».

---

Un merci spécial à Justin Drake et Tim Beiko pour leurs commentaires et commentaires.

Certaines choses sont difficiles à tomber dans une catégorie.Il y a beaucoup de « petites choses » dans la conception du protocole Ethereum qui sont très précieuses pour le succès d’Ethereum, mais elles ne conviennent pas pour être classées dans une sous-catégorie plus large.En fait, environ la moitié d’entre eux finissent par être associés à diverses améliorations EVM, tandis que le reste se compose de divers thèmes de niche.C’est à cela que sert « la folie ».

Splurge, 2023 Feuille de route

Les folies: objectifs principaux

• Amenez EVM à une performance élevée et à un « état final » stable « 

• Introduire l’abstraction du compte dans les protocoles afin que tous les utilisateurs puissent bénéficier de comptes plus sûrs et plus pratiques

• Optimiser l’économie des frais de transaction, améliorer l’évolutivité et réduire les risques

• Explorez les technologies de chiffrement avancées qui peuvent améliorer Ethereum à long terme

Améliorations EVM

Quels problèmes résout-il?

Les EVM d’aujourd’hui sont difficiles à effectuer une analyse statique, ce qui rend difficile la création d’implémentations efficaces, le code de vérification formelle et la mise à l’échelle plus loin au fil du temps.En outre, il est très inefficace, ce qui rend difficile la mise en œuvre de plusieurs formes de cryptage avancé à moins qu’ils ne soient explicitement pris 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 EVM est le format d’objet EVM (EOF), qui devrait être inclus dans la prochaine fourche dure.EOF est une série d’EIP utilisées pour spécifier de nouvelles versions de code EVM avec de nombreuses fonctionnalités uniques, notamment:

• Séparation entre le code (exécutable, mais non lu à partir de l’EVM) et les données (lisibles, mais pas exécutables).

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

• Le code EVM ne peut plus observer les informations liées au gaz.

• Ajout d’un nouveau mécanisme de sous-programme explicite.

Structure du code EOF

Les contrats à l’ancienne continueront d’exister et peuvent être créés, bien que les contrats à l’ancienne puissent éventuellement être obsolètes (et peut-être même les forcer à se convertir en code EOF).Les nouveaux contrats bénéficieront des gains d’efficacité apportés par EOF – Tout d’abord, avec les fonctions de sous-programme, le bytecode sera légèrement plus petit, puis de nouvelles fonctions spécifiques à l’EOF, ou les coûts de gaz spécifiques à l’EOF seront réduits.

Avec l’introduction de l’EOF, il est devenu plus facile d’introduire d’autres mises à niveau.La plus complète à l’heure actuelle est l’extension arithmétique modulaire EVM (EVM-MAX).EVM-Max crée un ensemble de nouvelles opérations conçues pour l’arithmétique modulaire et les place dans un nouvel espace mémoire qui n’est pas accessible à d’autres opodes.Cela permet d’utiliser des optimisations, telles que la multiplication de Montgomery.

Une idée plus récente est de combiner EVM-Max avec des capacités multi-données (SIMD) d’instructions unique.SIMD a été une idée pour Ethereum depuis l’EIP-616 de Greg Colvin.SIMD peut être utilisé pour accélérer une variété de formes de chiffrement, y compris les fonctions de hachage, le cryptage basé sur la matrice 32 bits et la matrice de points.EVM-Max et SIMD forment ensemble une paire d’extensions axées sur les performances d’EVM.

La conception approximative de l’EIP combinée commence par EIP-6690, puis:

• Permet (i) tout nombre impair ou (ii) toute puissance de 2 (jusqu’à 2 ^ 768) comme module

• Pour chaque opcode EVMMAX (ADD, sous, Mul), ajoutez une version. .Dans le code Python, ces opcodes effectueront des opérations équivalentes à ce qui suit:

Sauf dans la mise en œuvre réelle, il sera traité en parallèle.

• Si possible, ajoutez XOR, et, ou non, et Shift (Loop et acyclique) à au moins 2 modulo de puissance.A également ajouté Iszero (poussant la sortie vers la pile principale EVM).

Cela serait suffisamment puissant pour implémenter la cryptographie de la courbe elliptique, la cryptographie du petit domaine (par exemple, Poséidon, Circular Stark), les fonctions de hachage traditionnelles (par exemple, Sha256, Keccak, Blake) et la cryptographie à motif de matrice DOT.

D’autres mises à niveau EVM peuvent également être mises en œuvre, mais jusqu’à présent, elles ont reçu moins d’attention.

Quelles recherches sont-elles disponibles?

EOF:https://evmobjectformat.org/

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

Simd:https://eips.ethereum.org/eips/eip-616

Quelles sont les choses restantes à faire et quels compromis y a-t-il?

Actuellement, le plan EOF est inclus dans la prochaine fourche dure.Bien qu’il soit toujours possible de le retirer – la fonctionnalité de la fourche dure précédente a été supprimée à la dernière minute – ce serait une bataille difficile de le faire.La suppression de l’EOF signifie que l’EOF ne sera pas utilisé dans aucune mise à niveau future de l’EVM, ce qui peut être fait, mais peut être plus difficile.

Les principaux compromis pour EVM sont la complexité L1 et la complexité des infrastructures.EOF est beaucoup de code ajouté à l’implémentation EVM, et l’inspection du code statique est très complexe.Cependant, en échange, nous obtenons une simplification du langage de haut niveau, de la simplification de la mise en œuvre de l’EVM et d’autres avantages.On peut dire que la feuille de route pour hiérarchiser les améliorations continues à Ethereum L1 sera incluse et construite sur EOF.

Un travail important consiste à implémenter quelque chose comme EVM-Max Plus SIMD et Benchmark combien de gaz est requis pour diverses opérations de chiffrement.

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

L1 ajuste son EVM pour faciliter la L2 pour effectuer les mêmes ajustements.Un ajustement et l’autre ajustement entraîneront une certaine incompatibilité, qui a ses propres inconvénients.De plus, EVM-MAX plus SIMD peut réduire les coûts de gaz pour de nombreux systèmes de preuve, ce qui entraîne un L2 plus efficace.Il est également plus facile de supprimer plus de précompilations en les remplaçant par du code EVM qui peut effectuer les mêmes tâches sans avoir à avoir un grand impact sur l’efficacité.

Abstraction du compte

Quels problèmes résout-il?

Actuellement, les transactions ne peuvent être vérifiées que d’une manière: les signatures ECDSA.Initialement, l’abstraction du compte a été conçue pour aller au-delà et a permis à la logique de vérification du compte d’être un code EVM arbitraire.Cela peut réaliser une gamme d’applications:

• Passez à la technologie de chiffrement résistant aux quantités;

• Les vieilles touches tournantes (largement considérées comme une pratique de sécurité recommandée);

• Portefeuille multi-signature et portefeuille de récupération sociale;

• Signer les opérations de faible valeur avec une clé et des opérations de grande valeur avec une autre clé (ou un ensemble de clés);

• Permettre aux protocoles de confidentialité de fonctionner sans les répéteurs réduit considérablement sa complexité et élimine les dépendances centrales critiques.

Depuis le début de l’abstraction du compte en 2015, l’objectif s’est étendu pour inclure un grand nombre d ‘«objectifs de commodité» tels que No ETH, mais certains comptes ERC20 sont en mesure de payer du gaz avec cet ERC20.Le résumé de ces objectifs est indiqué dans le tableau suivant:

Ici, MPC est l’informatique multipartite: une technologie de 40 ans qui divise la clé en plusieurs parties, la stocke sur plusieurs appareils et génère des signatures en utilisant le cryptage sans combiner directement les parties individuelles de la clé.

EIP-7702 est un EIP prévu à être introduit dans la prochaine fourche dure.L’EIP-7702 est le résultat d’une reconnaissance croissante de la nécessité de fournir une abstraction de compte à tous les utilisateurs, y compris les utilisateurs d’EOA, pour améliorer l’expérience utilisateur de chacun à court terme et éviter de se diviser en deux écosystèmes.Ce travail a commencé avec EIP-3074 et a finalement atteint un sommet dans EIP-7702.EIP-7702 « Fonction de commodité » qui rend le résumé du compte à la disposition de tous les utilisateurs, y compris l’EOA (comptes détenus à l’extérieur, c’est-à-dire des comptes contrôlés par la signature ECDSA).

D’après le graphique, nous pouvons voir que si certains défis (en particulier le défi de «commodité») peuvent être résolus par l’informatique multipartite ou les technologies progressives telles que l’EIP-7702, la plupart des objectifs de sécurité de la proposition initiale pour les comptes abstraits ne peuvent être que Rendu pour résoudre le problème initial: permettez au code du contrat intelligent de contrôler la vérification des transactions.La raison pour laquelle cela n’a pas été fait jusqu’à présent est que la mise en œuvre en toute sécurité est un défi.

qu’est-ce que c’est?Comment ça marche?

Essentiellement, l’abstraction du compte est simple: permettre de lancer des transactions via des contrats intelligents (pas seulement l’EOA).Toute la complexité vient de cela d’une manière qui facilite la maintenance de réseaux décentralisés et empêche les attaques de déni de service.

Un exemple illustratif d’un défi clé est le problème d’invalidation multiple:

S’il y a 1000 comptes les fonctions de validation reposent toutes sur une seule valeur S et qu’il existe des transactions valides en fonction de la valeur actuelle de S dans le pool de mémoire, une transaction qui retourne la valeur S peut invalider toutes les autres transactions dans le pool de mémoire.Cela permet à un attaquant de spammer le pool de mémoire à très faible coût, bloquant les ressources du nœud de réseau.

Au fil des ans, les efforts pour étendre les capacités tout en limitant les risques DOS ont conduit à un accord sur les solutions pour parvenir à «l’abstraction de compte idéal»: ERC-4337.

La façon dont ERC-4337 fonctionne consiste à diviser le traitement des opérations utilisateur en deux étapes: vérification et exécution.Toutes les validations sont d’abord traitées, puis toutes les exécutions sont traitées.Dans le pool de mémoire, les opérations utilisateur ne sont acceptées que lorsque la phase de vérification de l’opération utilisateur ne touche que son propre compte et ne lit pas les variables d’environnement.Cela empêche plusieurs attaques invalides.L’étape de vérification applique également des restrictions strictes sur le gaz.

ERC-4337 a été conçu comme une norme hors protocole (ERC) car les développeurs de clients Ethereum se sont concentrés sur la fusion à l’époque et n’avaient pas de capacité supplémentaire pour gérer d’autres fonctions.C’est pourquoi ERC-4337 utilise ses propres objets (appelés opérations utilisateur) au lieu de transactions régulières.Cependant, nous avons récemment réalisé la nécessité d’inclure au moins une partie de cela dans l’accord.Deux raisons principales sont:

• Le point d’entrée est intrinsèquement inefficace en tant que contrat: fixé ~ 100k de frais de gaz par paquet et milliers de frais supplémentaires par opération utilisateur;

• Il est nécessaire de s’assurer que les propriétés Ethereum (telles que les garanties d’inclusion créées par les listes d’inclusion) continuent à l’utilisateur abstrait du compte.

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

• Payer: La fonctionnalité qui permet à un compte de payer des frais au nom d’un autre compte.Cela viole la règle qui n’accède qu’à le compte de l’expéditeur lui-même pendant la phase de vérification, de sorte que un traitement spécial est introduit pour permettre le mécanisme du payeur et s’assurer qu’il est sécurisé.

• AGLÉGATEUR: prend en charge les fonctionnalités d’agrégation de signature telles que l’agrégation BLS ou l’agrégation basée sur Snark.Ceci est nécessaire pour atteindre l’efficacité des données la plus élevée sur le résumé.

Quelles recherches sont-elles disponibles?

Historique abstrait des comptes Introduction: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 bwallet (en utilisant la fonction d’agrégation):https://github.com/getwax/bls-wallet

EIP-7562 (Résumé du compte Embed):https://eips.ethereum.org/eips/eip-7562

EIP-7701 (EFO basé sur EOF AA):https://eips.ethereum.org/eips/eip-7701

Quelles sont les choses restantes à faire et quels compromis y a-t-il?

La principale question restante est de savoir comment intégrer pleinement l’abstraction du compte dans l’accord.L’abstraction du compte le plus populaire EIP est EIP-7701, qui met en œuvre l’abstraction du compte en plus de l’EOF.Un compte peut avoir une section de code distincte pour la vérification, et si le compte a défini la section Code, le code sera exécuté à l’étape de vérification de la transaction du compte.

Structure du code EOF pour le compte EIP-7701

Ce qui est fascinant dans cette approche, c’est qu’elle montre clairement deux façons équivalentes de voir les abstractions du compte indigène:

• EIP-4337, mais dans le cadre du protocole

• Un nouveau type d’EOA où l’algorithme de signature est une exécution de code EVM

If we first strictly limit the complexity of the code executable during verification – not allowing external state access, or even setting the gas limit too low at the beginning to be used for quantum-resistant or privacy-protected applications – then this The security of the La méthode est très évidente: il remplace simplement la vérification ECDSA par l’exécution du code EVM qui nécessite un temps similaire.Cependant, au fil du temps, nous devons assouplir ces restrictions, comme permettant aux applications de protection de confidentialité de fonctionner sans répéteur et de résister à le quantum.Pour ce faire, nous devons vraiment trouver des moyens de résoudre les risques DOS d’une manière plus flexible sans avoir besoin d’étapes de vérification extrêmement simples.

Le compromis principal semble être de « prendre quelque chose dont moins de gens sont satisfaits dès que possible » plutôt que « attendre plus longtemps et peut-être obtenir une solution plus idéale ».L’approche idéale pourrait être une sorte d’approche mixte.Une approche hybride consiste à prendre certains cas d’utilisation comme guide plus rapidement et à laisser plus de temps pour en résoudre les autres.Une autre approche consiste à déployer d’abord une version abstraite plus ambitieuse du compte sur L2.Cependant, cela a le défi que pour une équipe L2 disposée à travailler dur pour adopter la proposition, ils doivent être sûrs que L1 et / ou d’autres L2 adopteront quelque chose de compatible plus tard.

Une autre application que nous devons envisager explicitement est le compte de clés, qui stocke l’état associé au compte sur L1 ou L2 dédié, mais peut être utilisé sur L1 et tout L2 compatible.Cela peut nécessiter efficacement L2 de prendre en charge les opcodes tels que L1Sload ou RemoteStaticCall, bien qu’il nécessite également une implémentation abstraite de compte sur L2 pour le prendre en charge.

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

Les listes incluses nécessitent une prise en charge des transactions abstraites de compte.En fait, les exigences pour inclure des listes sont finalement très similaires à celles des pools de mémoire décentralisés, bien que la flexibilité d’inclure des listes soit légèrement plus élevée.En outre, idéalement, les implémentations abstraites de compte devraient être coordonnées sur L1 et L2 autant que possible.Si à l’avenir, nous nous attendons à ce que la plupart des utilisateurs utilisent le résumé des mlés, alors la conception d’abstraction du compte devrait en tenir compte.

Améliorations EIP-1559

Quels problèmes résout-il?

L’EIP-1559 a été lancé sur Ethereum en 2021 et a considérablement amélioré le temps d’inclusion de bloc moyen.

Cependant, la mise en œuvre actuelle de l’EIP-1559 n’est pas parfaite de plusieurs manières:

• La formule est légèrement défectueuse: au lieu de cibler 50% des blocs, il cible ~ 50 à 53% des blocs complets en fonction de la variance (ceci est lié à ce que les mathématiciens appellent «l’inégalité AM-GM»);

• Il ne s’ajuste pas assez rapidement dans des conditions extrêmes.

La formule utilisée plus tard pour les blobs (EIP-4844) a été clairement conçue pour résoudre le premier problème et était généralement plus concise.Ni EIP-1559 lui-même ni EIP-4844 n’ont tenté de résoudre le deuxième numéro.Par conséquent, le statu quo est un état déroutant de l’abandon à mi-chemin impliquant deux mécanismes différents, et même l’un est que les deux ont besoin d’une amélioration au fil du temps.

De plus, la tarification des ressources Ethereum a d’autres faiblesses qui ne sont pas liées à l’EIP-1559, mais peuvent être résolues en ajustant l’EIP-1559.Un problème majeur est la différence entre le scénario moyen et le pire des cas: le prix des ressources dans Ethereum doit être défini pour être en mesure de gérer le pire des cas, c’est-à-dire que l’ensemble du gaz d’un bloc consomme une ressource, mais l’utilisation moyenne est beaucoup plus faible de cette manière, l’inefficacité est causée.

qu’est-ce que c’est?Comment ça marche?

La solution à ces problèmes d’inefficacité est le gaz multidimensionnel: fixer des prix et des restrictions différents sur différentes ressources.Ce concept est techniquement indépendant de l’EIP-1559, mais EIP-1559 facilite: sans EIP-1559, l’emballage optimal de blocs avec plusieurs contraintes de ressources est un problème de randonnée multidimensionnel complexe.Avec EIP-1559, la plupart des blocs ne sont pas entièrement chargés sur aucune ressource, donc un simple algorithme de « accepter tout ce qui paie suffisamment » est suffisant.

Nous avons du gaz multidimensionnel pour l’exécution et les blobs aujourd’hui;

EIP-7706 introduit une nouvelle dimension de gaz aux données d’appel.Dans le même temps, il résout également les défauts mathématiques de l’EIP-1559 en simplifiant le mécanisme de gaz multidimensionnel en faisant appartenir les trois types de gaz à un cadre (style EIP-4844).

L’EIP-7623 est une solution plus précise aux problèmes de ressources moyens et les pires des cas, ce qui limite plus strictement les données d’appel maximales sans introduire des dimensions complètement nouvelles.

Une autre direction consiste à résoudre le problème du taux de mise à jour et à trouver un algorithme de calcul de frais de base plus rapide tout en conservant les principaux invariants introduits par le mécanisme EIP-4844 (c’est-à-dire que l’utilisation moyenne est complètement proche de la cible à long terme).

Quelles recherches sont-elles disponibles?

FAQ EIP-1559:https://notes.ethereum.org/@vbuterin/eip-1559-faq

EIP-1559 Analyse empirique:https://dl.acm.org/doi/10.1145/3548606.3559341

Améliorations recommandées pour permettre des ajustements rapides:https://kclpure.kcl.ac.uk/ws/portalfiles/portal/180741021/transaction_fees_on_a_honeymoon_ethereums_eip_1559_one_month_later.pdf

FAQ EIP-4844, section sur le mécanisme de base des frais:https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#how-does-the-exponential-eip-1559-blob-fee-adjustment-mecanism-works

EIP-7706:https://eips.ethereum.org/eips/eip-7706

EIP-7623:https://eips.ethereum.org/eips/eip-7623

Gaz multidimensionnel:https://vitalik.eth.limo/general/2024/05/09/multidim.html

Quelles sont les choses restantes à faire et quels compromis y a-t-il?

Il existe deux compromis principaux pour le gaz multidimensionnel:

• Il augmente la complexité du protocole

• Il augmente la complexité du meilleur algorithme requis pour remplir les blocs de capacité

La complexité du protocole est un problème relativement petit pour CallData, mais un problème plus important pour les dimensions de gaz «à l’intérieur de l’EVM» (comme le stockage de lecture et d’écriture).Le problème est que ce n’est pas seulement les limites de gaz de définition de l’utilisateur: les contrats définissent également des restrictions lors de l’appel d’autres contrats.Et maintenant, la seule façon de fixer des restrictions est unidimensionnelle.

Un moyen facile d’éliminer ce problème est de rendre le gaz multidimensionnel disponible uniquement à l’intérieur de l’EOF, car l’EOF ne permet pas aux contrats de fixer des limites de gaz lors de l’appel d’autres contrats.Les contrats non-EFO doivent payer tous les types de frais de gaz lors de l’exécution des opérations de stockage (par exemple, si Sload dépense 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 pour l’exécution)

Faire plus de recherches sur le gaz multidimensionnel aidera à comprendre les compromis et à trouver l’équilibre idéal.

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

La mise en œuvre réussie de gaz multidimensionnel peut considérablement réduire l’utilisation de certaines ressources « pires », réduisant ainsi la pression pour optimiser les performances pour soutenir les arbres binaires basés sur un hachage frappant, par exemple.La fixation d’une cible dure pour la croissance de la taille de l’État permettra aux développeurs des clients de planifier et d’estimer plus facilement leurs besoins futurs.

Comme mentionné ci-dessus, parce que l’EOF est le gaz non observable, les versions multidimensionnelles plus extrêmes du gaz sont plus faciles à mettre en œuvre.

Fonction de retard vérifié (VDF)

Quels problèmes résout-il?

Aujourd’hui, Ethereum utilise un aléatoire basé sur Randao pour sélectionner les proposants.Le principe de travail de l’aléatoire basé sur Randao est de nécessiter que chaque proposant révèle les secrets qu’ils ont promis à l’avance et de mélanger chaque secret divulgué dans le caractère aléatoire.Par conséquent, chaque proposant a une «manipulation 1 bits à droite»: ils peuvent changer le caractère aléatoire en ne se présentant pas (à un prix).Ceci est raisonnable pour le proposant, car peu de gens peuvent se donner deux nouvelles opportunités de proposition en abandonnant une.Mais pour les applications en chaîne qui nécessitent un aléatoire, ce n’est pas possible.Idéalement, nous trouverions une source plus forte d’aléatoire.

qu’est-ce que c’est?Comment ça marche?

Une fonction de retard vérifiable est une fonction qui ne peut être calculée que dans l’ordre et ne peut pas être accélérée par parallélisation.Un exemple simple consiste à répéter le hachage: calculer i: x = hachage (x) dans la plage (10 ** 9).La sortie est prouvée par l’exactitude Snark et peut être utilisée comme valeur aléatoire.L’idée est que l’entrée est sélectionnée sur la base des informations disponibles au temps t, tandis que la sortie n’est pas claire au temps t: elle ne sera disponible qu’à un moment donné après que une personne eut entièrement exécuté le calcul.Parce que n’importe qui peut exécuter le calcul, il est impossible de cacher les résultats et n’a donc pas la capacité de manipuler les résultats.

Le principal risque de fonction de retard vérifiable est l’optimisation inattendue: quelqu’un a compris comment exécuter la fonction à un rythme beaucoup plus rapide que prévu, ce qui leur permet de manipuler les informations qu’il révèle au temps t en fonction de la sortie future.Une optimisation inattendue peut se produire de deux manières:

• Accélération matérielle: quelqu’un a fait une ASIC dont la boucle de calcul fonctionne beaucoup plus rapidement que le matériel existant.

• Parallélisation inattendue: quelqu’un a trouvé un moyen d’exécuter la fonction plus rapidement grâce à la parallélisation, même si elle prend plus de 100 fois la ressource.

La tâche de créer un VDF réussi est d’éviter les deux problèmes tout en restant efficace et pratique (par exemple, un problème avec les approches basées sur le hachage est que le SNARK en temps réel s’avère être requis sur le matériel).L’accélération matérielle est souvent résolue en permettant aux acteurs d’intérêt public de créer et de distribuer raisonnablement près des ASIC optimaux pour les VDF eux-mêmes.

Quelles recherches sont-elles disponibles?

vdfresearch.org:https://vdfresearch.org/

Réflexions sur les attaques sur les VDF utilisées dans Ethereum en 2018:https://ethresear.ch/t/veifiable-delay-functions-and-attacks/2365

Attaque contre Minroot (un VDF proposé):https://inria.hal.science/hal-04320126/file/minrootanalysis2023.pdf

Quelles sont les choses restantes à faire et quels compromis y a-t-il?

À l’heure actuelle, il n’y a pas de structure VDF qui répond pleinement à tous les besoins des chercheurs d’Ethereum.Plus de travail est nécessaire pour trouver de telles fonctionnalités.Si nous l’avons, le compromis principal est simplement de savoir s’il est inclus: un simple compromis entre la fonctionnalité et la complexité du protocole et les risques de sécurité.Si nous pensons que le VDF est sûr, mais finalement dangereux, la sécurité sera rétrogradée à l’hypothèse de Randao (manipulation 1 bits par attaquant) ou pire, selon la façon dont elle est mise en œuvre.Ainsi, même si le VDF est cassé, il brisera le protocole, mais il brisera l’application ou toute nouvelle fonctionnalité de protocole qui s’appuie fortement sur lui.

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

Le VDF est un composant relativement indépendant du protocole Ethereum, mais en plus d’améliorer la sécurité du choix du proposant, il peut également être utilisé pour (i) des applications sur chaîne qui reposent sur le hasard, ainsi que la mémoire cryptée potentiellement (II) Pools.

Une chose à retenir est que compte tenu de l’incertitude matérielle, il y aura un « écart » entre la génération de sortie VDF et la sortie.Cela signifie que les informations seront disponibles avant plusieurs blocs.Cela peut être un coût acceptable, mais doit être pris en compte dans une conception de finalité à machines à sous ou de comité, etc.

Confusion et signature unique: l’avenir de la cryptographie

Quels problèmes résout-il?

L’un des articles les plus célèbres de Nick Saab était un article de 1997 sur «l’accord de Dieu».Dans cet article, il note que les applications multipartites s’appuient souvent sur des « tiers de confiance » pour gérer les interactions.À son avis, le rôle de la cryptographie est de créer un tiers de confiance simulé pour faire le même travail sans exiger réellement de la confiance dans un participant particulier.

« Protocole de confiance mathématique », graphique dessiné par Nick Szabo

Jusqu’à présent, nous ne pouvons qu’approcher partiellement de cet idéal.Si tout ce dont nous avons besoin est un ordinateur virtuel transparent où les données et l’informatique ne peuvent pas être fermés, censurés ou falsifiés, mais la confidentialité n’est pas l’objectif, alors la blockchain peut le faire, bien qu’avec une évolutivité limitée.Si la confidentialité est un objectif, jusqu’à récemment, nous ne pouvions développer que des protocoles spécifiques pour des applications spécifiques: signatures numériques pour l’authentification de base, les signatures anonnées pour les formulaires anonymes originaux et les signatures annulaires liées, le cryptage basé sur l’identité (implémentez un cryptage plus pratique sous des hypothèses spécifiques pour la confiance de fiducie de confiance en fiducie fiable pour la confiance de fiducie pour fiducie de confiance en fiducie fiable pour la confiance de fiducie de confiance de confiance de confiance en fiducie fiable pour fiducie de confiance en fiducie fiable pour la confiance de fiducie pour fiducie de confiance en fiducie fiable pour la confiance de fiducie pour fiducie de confiance en fiducie fiable pour fiducie de confiance en fiducie fiable pour fiducie de confiance en fiducie fiable pour fiducie de confiance en fiducie fiable pour Trusted en fiabilité émetteurs), signatures aveugles pour la trésorerie électronique chaumienne, etc.Cette approche nécessite beaucoup de travail à faire pour chaque nouvelle application.

Dans les années 2010, nous avons vu pour la première fois une approche différente et plus puissante basée sur un chiffrement programmable.Au lieu de créer un nouveau protocole pour chaque nouvelle application, nous pouvons ajouter des garanties de chiffrement à tout programme utilisant de nouveaux protocoles puissants (en particulier ZK-Snark).ZK-SNARK permet aux utilisateurs de prouver toute déclaration des données qu’ils détiennent: prouver (i) facile à vérifier, et (ii) aucune donnée autre que l’instruction elle-même n’est divulguée.Il s’agit d’une énorme avancée pour l’intimité et l’évolutivité, et je le compare à l’effet du transformateur dans l’intelligence artificielle.Des milliers de personnes ont un an de travail d’application spécifique soudainement remplacée par une solution universelle que vous pouvez résoudre une gamme étonnamment large de problèmes avec juste le branchement.

Mais ZK-Snark n’est que le premier des trois primitives universelles similaires extrêmement puissantes.Ces protocoles sont si puissants que lorsque je pense à eux, ils me rappellent un ensemble de cartes extrêmement puissant dans Yu-Gi-Oh, un jeu de cartes et une émission de télévision que j’ai joué en tant qu’enfant souvent et voir: Card de Dieu égyptien.Les cartes de Dieu égyptien sont trois cartes extrêmement puissantes, et selon la légende, les faire peut être fatale et si puissante qu’elles ne sont pas autorisées à être utilisées dans les duels.De même, en cryptographie, nous avons trois protocoles de dieu égyptien:

qu’est-ce que c’est?Comment ça marche?

ZK-Snark est l’un des trois protocoles que nous avons déjà et avons atteint un niveau élevé de maturité.Au cours des cinq dernières années, ZK-Snark a fait d’énormes progrès pour prouver la vitesse et la convivialité des développeurs et est devenu la pierre angulaire des politiques d’évolutivité et de confidentialité d’Ethereum.Mais ZK-Snark a une limitation importante: vous devez connaître les données pour le prouver.Chaque état de l’application ZK-Snark doit avoir un « propriétaire » qui doit être présent pour approuver toutes les lectures ou les écrire.

Le deuxième protocole n’a pas cette limitation, à savoir le cryptage entièrement homomorphe (FHE).FHE vous permet d’effectuer des calculs sur les données cryptées sans les visualiser.Cela vous permet d’effectuer des calculs sur les données de l’utilisateur au profit des utilisateurs tout en conservant les données et les algorithmes privés.Il vous permet également d’étendre les systèmes de vote comme MACI pour des garanties de sécurité et de confidentialité presque parfaites.Fhe a longtemps été considéré comme trop inefficace pour être pratique, mais maintenant il est finalement devenu suffisamment efficace pour que nous commencions à voir des applications.

Cursive est une application qui utilise à la fois l’informatique et la découverte de confidentialité.

Mais FHE a également ses limites: toute technologie basée sur FHE exige toujours que quelqu’un détienne la clé de décryptage.Il peut s’agir d’une configuration distribuée M-OF-N, vous pouvez même ajouter une défense de couche 2 à l’aide de Tee, mais c’est toujours une limitation.

Cela nous donne un troisième protocole, qui est plus puissant que les deux autres protocoles combinés: confusion indiscernable.Bien qu’il soit loin d’être mature, à partir de 2020, nous avons développé des protocoles théoriquement valides basés sur des hypothèses de sécurité standard et récemment commencé à mettre en œuvre des travaux.L’obscurcissement indiscernable vous permet de créer un « programme crypté » qui effectue des calculs arbitraires, afin que tous les détails internes du programme soient cachés.Pour donner un exemple simple, vous pouvez mettre la clé privée dans un programme obscurci qui vous permet uniquement de l’utiliser pour signer des nombres premiers et distribuer le programme à d’autres.Ils peuvent utiliser le programme pour signer des nombres premiers, mais ils ne peuvent pas récupérer la clé.Mais il fait bien plus que cela: il peut être utilisé avec le hachage, et il peut être utilisé pour implémenter tout autre primitif de cryptage, et encore plus.

La seule chose qu’un programme obscurci ne peut pas faire est d’empêcher de copier.Mais pour cela, il y a quelque chose de plus puissant sur le point de venir, bien que cela dépend de tous ceux qui ont un ordinateur quantique: une signature quantique unique.

En utilisant l’obscurcissement et les signatures uniques, nous pouvons construire des tiers presque parfaits et sans confiance.La seule chose que nous ne pouvons pas faire avec la technologie de chiffrement est ce dont nous avons encore besoin de la blockchain, c’est-à-dire pour assurer la résistance à la censure.Ces technologies nous permettent non seulement de rendre Ethereum lui-même plus sécurisé, mais également de créer des applications plus puissantes en plus d’Ethereum.

Pour comprendre comment chacune de ces primitives ajoute des fonctionnalités supplémentaires, examinons un exemple clé: le vote.Le vote est une question fascinante car elle a de nombreux attributs de sécurité délicats qui doivent être respectés, y compris une vérifiabilité et une vie privée très fortes.Bien que les protocoles de vote avec une forte sécurité existent depuis des décennies, rendant le problème plus difficile en disant que nous voulons une conception qui peut gérer les protocoles de vote arbitraire: vote secondaire, financement secondaire délimité par des grappes, financement secondaire, etc.C’est-à-dire que nous voulons que l’étape « comptage du comte » soit une procédure arbitraire.

• Tout d’abord, disons que nous avons mis le vote publiquement sur la blockchain.Cela nous fournit une vérifiabilité publique (n’importe qui peut vérifier que le résultat final est correct, y compris les règles de comptage des votes et les règles d’admissibilité) et la résistance à la censure (qui ne peut pas empêcher les gens de voter).Mais nous n’avons aucune intimité.

• Ensuite, nous ajoutons ZK-Snark.Maintenant, nous avons la confidentialité: chaque vote est anonyme, tout en veillant à ce que seuls les électeurs autorisés puissent voter et que chaque électeur ne peut voter qu’une seule fois.

• Maintenant, nous ajoutons le mécanisme MACI.Le vote est chiffré à la clé de décryptage du serveur central.Le serveur central doit exécuter le processus de comptage des votes, notamment en rejetant les votes en double et en publiant ZK-Snark qui prouve la réponse.Cela conserve la garantie précédente (même si le serveur triche!), Mais si le serveur est honnête, il ajoute une garantie de résistance obligatoire: l’utilisateur ne peut pas prouver comment il a voté, même s’il le souhaite.En effet, si les utilisateurs peuvent prouver le vote qu’ils ont voté, ils ne peuvent pas prouver qu’ils n’ont pas fait un autre vote pour annuler le vote.Cela empêche la corruption et d’autres attaques.

• Nous exécutons le comptage en interne en FHE, puis le décryptons en effectuant des calculs de décryptage de seuil N / 2-N / 2.Cela rend la résistance obligatoire garantie à N / 2-OF-N, pas 1-of-of-1.

• Nous obscurcissons le processus de comptage et concevons le processus d’obscurcissement afin qu’il ne puisse donner la sortie que si elle est autorisée, qu’il s’agisse de preuve de consensus de la blockchain, ou par une certaine preuve de travail, ou les deux.Cela rend la résistance obligatoire garantie presque parfaite: dans le cas du consensus de la blockchain, vous avez besoin de 51% des validateurs pour le colluder, tandis que dans le cas de la preuve de travail, même si tout le monde se termine, relâche avec un sous-ensemble différent, le vote des électeurs des électeurs Dans une tentative d’extraction des électeurs individuels sera également très coûteux.Nous pouvons même demander au programme d’ajuster le résultat final légèrement au hasard, ce qui rend plus difficile d’extraire le comportement des électeurs individuels.

• Nous avons ajouté une signature unique, une primitive qui repose sur l’informatique quantique, permettant à des signatures d’être utilisées uniquement pour signer un message d’un certain type à la fois.Cela rend l’anti-dépression garantie la vraie perfection.

L’obscurcissement indiscriminatoire peut également permettre d’autres applications puissantes.Par exemple:

• DAO, enchères en chaîne et autres applications avec tout statut secret interne.

• Paramètres de confiance qui sont vraiment universels: quelqu’un peut créer un programme flou avec une clé, et peut exécuter n’importe quel programme et fournir une sortie, mettant le hash (clé, programme) dans le programme en entrée.Compte tenu d’un tel programme, n’importe qui peut mettre le programme en lui-même, combiner la clé existante du programme avec la leur et étendre les paramètres du processus.Cela peut être utilisé pour générer un paramètre de confiance 1-N pour n’importe quel protocole.

• ZK-Snarks, sa vérification n’est que la signature.La mise en œuvre est simple: il y a une configuration de confiance où quelqu’un crée un programme flou qui ne signera le message avec la clé que s’il s’agit d’un ZK-Snark valide.

• Pool à mémoire cryptée.Les transactions cryptographiques sont devenues si faciles qu’elles ne seront décryptées que si certains événements en chaîne se produisent à l’avenir.Cela peut même inclure une exécution réussie des VDF.

Avec des signatures ponctuelles, nous pouvons protéger la blockchain des attaques d’inversion finale de 51%, bien que des attaques de censure peuvent toujours exister.Les primitives similaires aux signatures uniques peuvent mettre en œuvre des devises quantiques et résoudre le problème de paiement double sans blockchain, bien que de nombreuses applications plus complexes nécessitent toujours la blockchain.

Si ces primitives sont suffisamment efficaces, la plupart des applications dans le monde peuvent être décentralisées.Le goulot d’étranglement principal réside dans la vérification de l’exactitude de la mise en œuvre.

Quelles recherches sont-elles disponibles?

L’accord d’obscurcissement indiscriminatoire de 2021:https://eprint.iacr.org/2021/1334.pdf

Confusion comment aider Ethereum:https://ethresear.ch/t/how-obfuscation-can-help-ethereum/7380

La première construction de signature unique connue:https://eprint.iacr.org/2020/107.pdf

Tentatives obscènes pour mettre en œuvre (1):https://mediatum.ub.tum.de/doc/1246288/1246288.pdf

Tentatives obscènes pour implémenter (2):https://github.com/sorasuegami/iomaker/tree/main

Quelles sont les choses restantes à faire et quels compromis y a-t-il?

Il y a encore beaucoup de choses à faire.La confusion indiscriminatoire est très immature et les constructions candidates sont des millions de fois plus lentes (ou même plus) que les applications.La confusion indiscriminatoire est connue pour le temps d’exécution du temps polynomial « en théorie », mais il faut plus de temps pour fonctionner dans la pratique que la durée de vie de l’univers.Les protocoles plus récents rendent les temps d’exécution moins extrêmes, mais les frais généraux sont encore trop élevés pour une utilisation régulière: un implémenteur s’attend à ce que l’exécution soit un an.

Les ordinateurs quantiques n’existent même pas: toutes les constructions que vous pouvez lire sur Internet aujourd’hui sont soit des prototypes qui ne peuvent pas effectuer de calculs supérieurs à 4 bits, soit ils ne sont pas vraiment des ordinateurs quantiques, et bien qu’ils puissent contenir des pièces quantiques, Ils ne peuvent pas exécuter vraiment de calcul du sens, comme l’algorithme de shor ou l’algorithme Grover.Récemment, il y a des signes que les «vrais» ordinateurs quantiques ne sont plus aussi loin.Cependant, même si des ordinateurs quantiques « réels » sortent bientôt, les jours où les gens ordinaires ont des ordinateurs quantiques sur leurs ordinateurs portables ou téléphones peuvent être des décennies plus tard que des institutions puissantes obtenant des ordinateurs quantiques qui peuvent casser les codes de courbe elliptique.

Un compromis clé pour la confusion indiscriminatoire est l’hypothèse de sécurité.Il existe des conceptions plus radicales qui utilisent des hypothèses étranges.Ceux-ci ont généralement des temps d’exécution plus réalistes, mais des hypothèses étranges sont parfois brisées.Au fil du temps, nous pouvons éventuellement avoir suffisamment de connaissances sur la cour pour faire des hypothèses qui ne seront pas brisées.Cependant, cette route est plus dangereuse.Une approche plus conservatrice consiste à s’en tenir aux protocoles où la sécurité peut être prouvée comme des hypothèses « standard », mais cela peut signifier qu’il nous faudra plus de temps pour obtenir un protocole qui fonctionne assez rapidement.

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

La technologie de chiffrement extrêmement puissante pourrait changer la donne.Par exemple:

• Si nous obtenons ZK-Snark qui est aussi facile à vérifier qu’une signature, nous n’avons peut-être pas besoin de protocole d’agrégation; nous pouvons le vérifier directement sur la chaîne.

• Les signatures uniques peuvent signifier un accord de preuve plus sûr.

• De nombreux protocoles de confidentialité complexes peuvent être remplacés par des EVM «seulement» protégées par la confidentialité.

• Les pools de mémoire chiffrés deviennent plus faciles à implémenter.

Premièrement, les avantages se produiront dans la couche de demande, car Ethereum L1 doit essentiellement être conservateur sur les hypothèses de sécurité.Cependant, même l’utilisation de la couche d’application seule peut changer la donne, tout comme l’avènement de ZK-Snark.