- Rubrique
15k Popularité
45k Popularité
2k Popularité
15k Popularité
30k Popularité
810 Popularité
109k Popularité
26k Popularité
26k Popularité
7k Popularité
- Épingler
15k Popularité
45k Popularité
2k Popularité
15k Popularité
30k Popularité
810 Popularité
109k Popularité
26k Popularité
26k Popularité
7k Popularité
La voie de la prospérité du protocole Ethereum : améliorations de l'EVM, abstraction de compte et Gas multidimensionnel
Avenir possible du protocole Ethereum (six) : chapitre de prospérité
Certaines choses sont difficiles à classer dans une seule catégorie. Dans la conception du protocole Ethereum, de nombreux « détails » sont essentiels au 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 le sens de « prospérité ».
Prospérité : objectif clé
amélioration EVM
Quel problème a été résolu ?
Actuellement, l'EVM est difficile à analyser statiquement, ce qui rend la création d'implémentations efficaces, la vérification formelle du code et l'extension ultérieure difficiles. De plus, l'efficacité de l'EVM est faible, rendant difficile la mise en œuvre de nombreuses formes de cryptographie avancée, sauf si un support explicite par précompilation est fourni.
Qu'est-ce que c'est et comment ça fonctionne ?
La première étape de la feuille de route d'amélioration de l'EVM actuelle est le format d'objet EVM (EOF), qui est prévu pour être inclus dans le prochain hard fork. L'EOF est une série d'EIP, spécifiant une nouvelle version du code EVM, avec de nombreuses caractéristiques uniques, la plus significative étant :
Les contrats anciens continueront d'exister et pourront être créés, bien qu'ils puissent finalement être progressivement abandonnés (et même être contraints de se convertir en code EOF). Les nouveaux contrats bénéficieront des gains d'efficacité apportés par le EOF.
Après l'introduction de l'EOS, les mises à niveau ultérieures deviennent plus faciles. Le développement le plus avancé actuellement est l'extension arithmétique du module EVM (EVM-MAX). EVM-MAX crée un ensemble de nouvelles opérations spécifiquement pour les opérations modulo et les place dans un nouvel espace mémoire inaccessible par d'autres codes opérationnels, ce qui rend possible l'utilisation d'optimisations telles que la multiplication de Montgomery.
Une idée plus récente est de combiner EVM-MAX avec les caractéristiques SIMD (Single Instruction, Multiple Data). SIMD, en tant que concept d'Ethereum, existe depuis longtemps, ayant été proposé pour la première fois par Greg Colvin dans l'EIP-616. SIMD peut être utilisé pour accélérer de nombreuses formes de cryptographie, y compris les fonctions de hachage, les STARKs de 32 bits et la cryptographie basée sur les réseaux. La combinaison d'EVM-MAX et de SIMD fait de ces deux extensions axées sur la performance un couple naturel.
Liens de recherche existants
Le travail restant et les compromis
Actuellement, EOF est prévu pour être inclus dans le prochain hard fork. Bien qu'il soit toujours possible de le retirer à la dernière minute, cela représenterait un grand défi. Retirer EOF signifie que toute mise à niveau future de l'EVM devra se faire sans EOF, ce qui est possible, mais cela pourrait être plus difficile.
Le principal compromis de l'EVM réside dans la complexité de L1 et la complexité de l'infrastructure. L'EOF nécessite l'ajout d'un grand nombre de lignes de code à l'implémentation de l'EVM, et l'analyse statique du code est également relativement complexe. Cependant, en échange, nous pouvons simplifier les langages de haut niveau, simplifier l'implémentation de l'EVM et bénéficier d'autres avantages. On peut dire que la feuille de route priorisant l'amélioration continue d'Ethereum L1 devrait inclure et s'appuyer sur l'EOF.
Un travail important à réaliser est de mettre en œuvre des fonctionnalités similaires à EVM-MAX avec SIMD et de réaliser des tests de référence sur la consommation de gas des différentes opérations cryptographiques.
Comment interagir avec les autres parties de la feuille de route ?
L1 ajuste son EVM afin que L2 puisse également effectuer des ajustements correspondants plus facilement. Si les deux ne sont pas ajustés de manière synchronisée, cela pourrait entraîner des incompatibilités et des effets néfastes. De plus, EVM-MAX et SIMD peuvent réduire le coût en gas de nombreux systèmes de preuve, rendant ainsi L2 plus efficace. Cela facilite également le remplacement de davantage de précompilés par du code EVM pouvant exécuter les mêmes tâches, ce qui pourrait ne pas avoir un impact significatif sur l'efficacité.
abstraction de compte
Quel problème a été résolu ?
Actuellement, les transactions ne peuvent être vérifiées que par un moyen : la signature ECDSA. À l'origine, l'abstraction de compte visait à aller au-delà de cela, permettant à la logique de vérification des comptes d'être n'importe quel code EVM. Cela peut activer une gamme d'applications :
Depuis que l'abstraction de compte a été proposée en 2015, son objectif s'est également étendu pour inclure de nombreux « objectifs de commodité », par exemple, un compte sans ETH mais possédant des ERC20 peut payer le gas avec des ERC20.
Qu'est-ce que c'est et comment ça fonctionne ?
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é vient de la manière de réaliser cela d'une manière qui favorise le maintien d'un réseau décentralisé et de prévenir les attaques par déni de service.
Après des années d'efforts visant à étendre les fonctionnalités tout en limitant les risques d'attaque par déni de service (DoS), une solution pour réaliser "l'abstraction de compte idéale" a finalement été trouvée : ERC-4337.
Le fonctionnement de l'ERC-4337 consiste à diviser le traitement des opérations des utilisateurs en deux étapes : validation et exécution. Toutes les validations sont d'abord traitées, suivies de toutes les exécutions. Dans la mémoire tampon, les opérations des utilisateurs ne sont acceptées que lorsque la phase de validation n'implique que leur propre compte et ne lit pas les variables d'environnement. Cela permet d'éviter les attaques par défaillance multiple. De plus, des limites de gas strictes sont également imposées aux étapes de validation.
Liens de recherche existants
Les travaux restants et les compromis
Actuellement, le principal problème à résoudre est comment intégrer complètement l'abstraction de compte dans le protocole. Le récent EIP sur l'abstraction de compte, qui a gagné en popularité, est l'EIP-7701, qui met en œuvre l'abstraction de compte au-dessus de l'EOF. Un compte peut avoir une partie de code distincte pour la vérification, et si ce compte a défini cette partie de code, celle-ci sera exécutée lors de l'étape de validation des transactions provenant de ce compte.
Le principal compromis semble être « écrire rapidement une solution qui satisfait moins de personnes » contre « attendre plus longtemps pour peut-être obtenir une solution plus idéale », la méthode idéale pourrait être une sorte d'approche mixte. Une approche mixte consiste à écrire plus rapidement certains cas d'utilisation, tout en laissant plus de temps pour explorer d'autres cas d'utilisation. Une autre méthode consiste à déployer d'abord une version plus ambitieuse d'abstraction de compte sur L2.
Comment 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, la demande de liste d'inclusion est en réalité très similaire à celle des pools de mémoire décentralisés, bien que la flexibilité soit légèrement plus grande pour les listes d'inclusion. De plus, l'implémentation de l'abstraction de compte devrait, autant que possible, réaliser une coordination entre L1 et L2. Si nous prévoyons que la plupart des utilisateurs utiliseront le Rollup de stockage de clés à l'avenir, la conception de l'abstraction de compte devrait être basée sur cela.
amélioration EIP-1559
Quel problème cela résout-il ?
EIP-1559 a été activé sur Ethereum en 2021, améliorant considérablement le temps moyen d'inclusion des blocs.
Cependant, la mise en œuvre actuelle de l'EIP-1559 n'est pas parfaite à plusieurs égards :
La formule pour les blobs (EIP-4844) est spécialement conçue pour résoudre le premier problème, et dans l'ensemble, elle est également plus concise. Cependant, EIP-1559 lui-même ainsi que EIP-4844 n'ont pas tenté de résoudre le deuxième problème.
De plus, il existe d'autres faiblesses dans la tarification des ressources Ethereum qui ne sont pas 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 la situation moyenne et la pire situation : le prix des ressources dans Ethereum doit être fixé de manière à pouvoir gérer la pire situation, c'est-à-dire que la consommation totale de gas d'un bloc occupe une ressource, mais l'utilisation réelle moyenne est bien inférieure, ce qui entraîne de l'inefficacité.
Qu'est-ce que le Gas multidimensionnel et comment fonctionne-t-il ?
La solution à ces problèmes d'inefficacité est le Gas multidimensionnel : définir 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 rend la mise en œuvre de cette solution plus facile. Sans l'EIP-1559, le conditionnement optimal d'un bloc contenant diverses contraintes de ressources serait un problème complexe de sac à dos multidimensionnel. Avec l'EIP-1559, la plupart des blocs ne seront pas chargés à pleine capacité sur n'importe quelle ressource, donc un algorithme aussi simple que "accepter toute transaction payant des frais suffisants" est suffisant.
Actuellement, nous disposons d'un Gas multidimensionnel pour l'exécution et les blocs de données ; en principe, nous pouvons l'étendre à plus de dimensions : comme calldata (données de transaction), lecture / écriture d'état, et extension de la taille de l'état.
EIP-7706 introduit une nouvelle dimension de gas, spécifiquement pour le calldata. En même temps, il simplifie le mécanisme multi-dimensionnel de Gas en unifiant trois types de gas dans un cadre (de style EIP-4844), résolvant ainsi les défauts mathématiques de l'EIP-1559. L'EIP-7623 est une solution plus précise, qui aborde les problèmes de ressources en cas de moyenne et de pire situation, en limitant plus strictement le maximum de calldata sans introduire toute une nouvelle dimension.
Liens de recherche existants