Les directions futures possibles du protocole Ethereum : Épisode prospère
Dans la conception du protocole Ethereum, de nombreux "détails" importants sont cruciaux pour son succès. Environ la moitié du contenu concerne différents types d'améliorations de l'EVM, le reste étant constitué de divers sujets de niche, c'est là que réside le sens de "prospérité".
Prospérité : objectif clé
Transformer l'EVM en un "état final" performant et stable.
Introduire l'abstraction de compte dans le protocole, permettant à tous les utilisateurs de bénéficier d'un compte plus sûr et plus pratique.
Optimiser l'économie des frais de transaction, améliorer l'évolutivité tout en réduisant les risques
Explorer la cryptographie avancée pour améliorer significativement Ethereum à long terme.
Amélioration de l'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'expansion ultérieure difficiles. De plus, l'EVM est peu efficace, rendant difficile la mise en œuvre de nombreuses formes de cryptographie avancée, sauf par un soutien explicite via des précompilations.
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), prévu pour être inclus dans la prochaine hard fork. EOF est une série d'EIP, qui spécifie une nouvelle version du code EVM, avec de nombreuses caractéristiques uniques, la plus notable étant :
Le code ( est exécutable, mais il est impossible de lire ) depuis l'EVM et les données ( peuvent être lues, mais il est impossible d'exécuter la séparation entre ).
Interdiction des redirections dynamiques, seulement des redirections statiques autorisées
Le code EVM ne peut plus observer les informations liées au combustible.
Ajout d'un nouveau mécanisme de sous-routine explicite
La structure du code EOF comprend une section de code, une section de données et une section d'informations de type.
Après l'introduction de l'Eof, les mises à niveau ultérieures deviennent plus faciles. Le développement le plus avancé est l'extension arithmétique du module EVM ( EVM-MAX ). EVM-MAX crée un ensemble de nouvelles opérations spécialement conçues pour les opérations modulo et les place dans un nouvel espace mémoire inaccessible par d'autres codes d'opération, 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 la caractéristique SIMD (Single Instruction Multiple Data) (. SIMD peut être utilisé pour accélérer de nombreuses formes de cryptographie, y compris les fonctions de hachage, les STARKs 32 bits et la cryptographie basée sur les réseaux. La combinaison d'EVM-MAX et de SIMD fait de ces deux extensions axées sur la performance un couple naturel.
) Liens de recherche existants
EOF:
EVM-MAX:
SIMD:
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 l'enlever à la dernière minute, cela représenterait un grand défi. Enlever EOF signifierait que toute mise à niveau future de l'EVM devrait se faire sans EOF, bien que cela soit possible, cela pourrait s'avérer plus difficile.
Le principal compromis de l'EVM réside dans la complexité de L1 et celle de l'infrastructure. L'EOF nécessite l'ajout d'un grand nombre de codes à l'implémentation de l'EVM, et la vérification 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 d'autres avantages. On peut dire que la feuille de route pour l'amélioration continue d'Ethereum L1 devrait inclure et s'appuyer sur l'EOF.
Un travail important à réaliser est d'implémenter des fonctionnalités similaires à EVM-MAX et SIMD, et de procéder à 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 pour permettre à L2 de s'ajuster plus facilement en conséquence. Si les deux ne sont pas synchronisés, cela pourrait entraîner des incompatibilités et avoir des effets négatifs. De plus, EVM-MAX et SIMD peuvent réduire le coût en gas de nombreux systèmes de preuve, rendant ainsi L2 plus efficace. Cela facilite également le remplacement de plus de précompilations par du code EVM capable d'exécuter les mêmes tâches, ce qui ne devrait pas avoir d'impact significatif sur l'efficacité.
![Vitalik sur l'avenir possible d'Ethereum (six) : The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
Abstraction de compte
) a résolu quel problème ?
Actuellement, les transactions ne peuvent être vérifiées que de manière : 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 série d'applications :
Passer à la cryptographie résistant aux quantiques
Le remplacement des anciennes clés ### est largement considéré comme une pratique de sécurité recommandée (
Portefeuille multi-signature et portefeuille de récupération sociale
Utiliser une clé pour des opérations de faible valeur, utiliser une autre clé ) ou un ensemble de clés ( pour des opérations de haute valeur
Permettre au protocole de confidentialité de fonctionner sans relais, réduisant ainsi considérablement sa complexité et éliminant un point de dépendance central clé.
Depuis que l'abstraction de compte a été proposée en 2015, son objectif s'est également étendu pour inclure de nombreux "objectifs pratiques", par exemple, un compte qui n'a pas d'ETH mais possède des ERC20 peut utiliser des ERC20 pour payer le gaz.
![Vitalik sur l'avenir possible d'Ethereum (six) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
) Qu'est-ce que c'est, 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é provient de la manière dont cela est réalisé de manière à préserver la décentralisation du réseau et à se prémunir contre les attaques par déni de service.
Un défi clé typique est le problème de la défaillance multiple : si 1000 comptes ont une fonction de validation qui dépend d'une seule valeur S, et que la valeur actuelle S rend toutes les transactions dans le pool de mémoire valides, alors une seule transaction inversant la valeur de S pourrait rendre toutes les autres transactions dans le pool de mémoire invalides. Cela permet à un attaquant d'envoyer des transactions indésirables au pool de mémoire à un coût très faible, ce qui obstrue les ressources des nœuds du réseau.
Après des années d'efforts, visant à étendre les fonctionnalités tout en limitant les risques de 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 d'ERC-4337 consiste à diviser le traitement des opérations utilisateur en deux phases : validation et exécution. Toute la validation est d'abord traitée, puis toute l'exécution. Dans le pool de mémoire, une opération utilisateur n'est acceptée que si la phase de validation ne concerne que son propre compte et ne lit pas les variables d'environnement. Cela peut prévenir les attaques par échec multiple. De plus, des limites strictes en matière de gaz sont également imposées à l'étape de validation.
![Vitalik sur l'avenir possible d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
) Liens de recherche existants
Discours sur l'histoire de l'abstraction de compte :
ERC-4337:
EIP-7702:
Le code BLSWallet ### utilise la fonction d'agrégation ( :
EIP-7562) écrit dans le protocole d'abstraction de compte ( :
EIP-7701) compte abstrait d'écriture basé sur EOF protocole (:
) Le travail restant et les compromis
La principale question à résoudre actuellement est comment intégrer complètement l'abstraction de compte dans le protocole. Le compte abstrait via le protocole récemment populaire est 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 validation, et si le compte a configuré cette partie de code, ce code sera exécuté lors de l'étape de validation des transactions provenant de ce compte.
Le charme de cette méthode réside dans le fait qu'elle indique clairement les deux perspectives équivalentes de l'abstraction du compte local :
Intégrer l'EIP-4337 en tant que partie du protocole
Un nouveau type d'EOA, dont l'algorithme de signature est l'exécution de code EVM
Si nous commençons par établir des limites strictes sur la complexité du code exécutable pendant la validation, alors la sécurité de cette approche est très claire : il suffit de remplacer la vérification ECDSA par une exécution de code EVM nécessitant un temps similaire.
Cependant, avec le temps, nous devons assouplir ces limites, car il est très important de permettre aux applications de protection de la vie privée de fonctionner sans relais, ainsi que d'assurer une résistance quantique. Pour cela, nous devons trouver des moyens plus flexibles de résoudre le risque de déni de service ###DoS(, sans exiger que les étapes de vérification doivent être extrêmement simplistes.
Le principal compromis semble être "écrire rapidement un plan 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 consisterait à écrire plus rapidement certains cas d'utilisation et à laisser plus de temps pour explorer d'autres cas d'utilisation. Une autre méthode serait de déployer d'abord une version d'abstraction de compte plus ambitieuse sur L2. Cependant, le défi auquel cela fait face est que l'équipe L2 doit avoir une confiance totale dans le travail d'adoption de la proposition pour être prête à la mettre en œuvre, en particulier pour s'assurer que L1 et/ou d'autres L2 pourront adopter des solutions compatibles à l'avenir.
Une autre application que nous devons clairement prendre en considération est le compte de stockage de clés, qui stocke l'état associé au compte sur L1 ou sur un L2 dédié, mais peut être utilisé sur L1 et tout L2 compatible. Pour y parvenir efficacement, il se peut que L2 doive prendre en charge des codes d'opération tels que L1SLOAD ou REMOTESTATICCALL, mais cela nécessite également que l'implémentation de l'abstraction des comptes sur L2 prenne en charge ces opérations.
) 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 mémoires tampons décentralisées, bien que la flexibilité soit légèrement plus grande pour la liste d'inclusion. De plus, la mise en œuvre de l'abstraction de compte devrait s'efforcer d'atteindre une coordination entre L1 et L2 autant que possible. Si nous prévoyons à l'avenir que la plupart des utilisateurs utiliseront des Rollup de stockage de clés, la conception de l'abstraction de compte devrait en tenir compte.
![Vitalik sur l'avenir possible d'Ethereum (6) : The Splurge]###https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
Amélioration EIP-1559
) Il résout quel problème ?
EIP-1559 a été activé sur Ethereum en 2021, améliorant considérablement le temps moyen d'inclusion des blocs. Cependant, l'implémentation actuelle d'EIP-1559 n'est pas parfaite à plusieurs égards :
La formule présente quelques défauts : elle ne vise pas 50 % des blocs, mais environ 50-53 % des blocs pleins, ce qui dépend de la variance ###, ce qui est lié à ce que les mathématiciens appellent "l'inégalité arithmético-géométrique" (.
Dans des cas extrêmes, les ajustements ne sont pas suffisamment rapides.
La formule pour les blobs )EIP-4844( est spécialement conçue pour résoudre le premier problème, et elle est globalement plus concise. Cependant, EIP-1559 lui-même ainsi qu'EIP-4844 n'ont pas tenté de résoudre le deuxième problème. Par conséquent, la situation actuelle est un état intermédiaire chaotique, impliquant deux mécanismes différents, et il y a un point de vue selon lequel, avec le temps, les deux nécessiteront des améliorations.
De plus, 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 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 le pire des cas, c'est-à-dire que la consommation totale de gas d'un bloc occupe une ressource, mais l'utilisation moyenne réelle est bien inférieure à cela, ce qui entraîne de l'inefficacité.
![Vitalik sur l'avenir possible d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-fe95dd28b911aea1a22365468b7c42cd.webp(
) 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 de l'EIP-1.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
14 J'aime
Récompense
14
7
Partager
Commentaire
0/400
MissedAirdropBro
· 07-26 03:16
Pourquoi encore l'abstraction de compte !
Voir l'originalRépondre0
BrokenDAO
· 07-25 06:25
Une autre feuille de route ambitieuse, qui risque fortement de reproduire le sort de Casper.
Voir l'originalRépondre0
GasGuru
· 07-24 20:52
Ça a l'air très fiable, oui.
Voir l'originalRépondre0
SigmaBrain
· 07-24 20:51
Qu'est-ce que c'est, cette version doit encore être modifiée ?
Voir l'originalRépondre0
OPsychology
· 07-24 20:45
Cette mise à niveau sera mise en ligne quel jour ?
Voir l'originalRépondre0
WalletWhisperer
· 07-24 20:31
les schémas comportementaux suggèrent qu'evm2.0 déclenchera des migrations massives de portefeuilles... statistiquement inévitables
Voir l'originalRépondre0
Whale_Whisperer
· 07-24 20:29
La mise à niveau de l'EVM aurait dû être évoquée plus tôt, ces frais de gas sont vraiment insupportables.
Futur du protocole Ethereum : mise à niveau de l'EVM, abstraction de compte et optimisation des frais
Les directions futures possibles du protocole Ethereum : Épisode prospère
Dans la conception du protocole Ethereum, de nombreux "détails" importants sont cruciaux pour son succès. Environ la moitié du contenu concerne différents types d'améliorations de l'EVM, le reste étant constitué de divers sujets de niche, c'est là que réside le sens de "prospérité".
Prospérité : objectif clé
Amélioration de l'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'expansion ultérieure difficiles. De plus, l'EVM est peu efficace, rendant difficile la mise en œuvre de nombreuses formes de cryptographie avancée, sauf par un soutien explicite via des précompilations.
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), prévu pour être inclus dans la prochaine hard fork. EOF est une série d'EIP, qui spécifie une nouvelle version du code EVM, avec de nombreuses caractéristiques uniques, la plus notable étant :
La structure du code EOF comprend une section de code, une section de données et une section d'informations de type.
Après l'introduction de l'Eof, les mises à niveau ultérieures deviennent plus faciles. Le développement le plus avancé est l'extension arithmétique du module EVM ( EVM-MAX ). EVM-MAX crée un ensemble de nouvelles opérations spécialement conçues pour les opérations modulo et les place dans un nouvel espace mémoire inaccessible par d'autres codes d'opération, 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 la caractéristique SIMD (Single Instruction Multiple Data) (. SIMD peut être utilisé pour accélérer de nombreuses formes de cryptographie, y compris les fonctions de hachage, les STARKs 32 bits et la cryptographie basée sur les réseaux. La combinaison d'EVM-MAX et de SIMD 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 l'enlever à la dernière minute, cela représenterait un grand défi. Enlever EOF signifierait que toute mise à niveau future de l'EVM devrait se faire sans EOF, bien que cela soit possible, cela pourrait s'avérer plus difficile.
Le principal compromis de l'EVM réside dans la complexité de L1 et celle de l'infrastructure. L'EOF nécessite l'ajout d'un grand nombre de codes à l'implémentation de l'EVM, et la vérification 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 d'autres avantages. On peut dire que la feuille de route pour l'amélioration continue d'Ethereum L1 devrait inclure et s'appuyer sur l'EOF.
Un travail important à réaliser est d'implémenter des fonctionnalités similaires à EVM-MAX et SIMD, et de procéder à 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 pour permettre à L2 de s'ajuster plus facilement en conséquence. Si les deux ne sont pas synchronisés, cela pourrait entraîner des incompatibilités et avoir des effets négatifs. De plus, EVM-MAX et SIMD peuvent réduire le coût en gas de nombreux systèmes de preuve, rendant ainsi L2 plus efficace. Cela facilite également le remplacement de plus de précompilations par du code EVM capable d'exécuter les mêmes tâches, ce qui ne devrait pas avoir d'impact significatif sur l'efficacité.
![Vitalik sur l'avenir possible d'Ethereum (six) : The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
Abstraction de compte
) a résolu quel problème ?
Actuellement, les transactions ne peuvent être vérifiées que de manière : 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 série d'applications :
Permettre au protocole de confidentialité de fonctionner sans relais, réduisant ainsi considérablement sa complexité et éliminant un point de dépendance central clé.
Depuis que l'abstraction de compte a été proposée en 2015, son objectif s'est également étendu pour inclure de nombreux "objectifs pratiques", par exemple, un compte qui n'a pas d'ETH mais possède des ERC20 peut utiliser des ERC20 pour payer le gaz.
![Vitalik sur l'avenir possible d'Ethereum (six) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
) Qu'est-ce que c'est, 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é provient de la manière dont cela est réalisé de manière à préserver la décentralisation du réseau et à se prémunir contre les attaques par déni de service.
Un défi clé typique est le problème de la défaillance multiple : si 1000 comptes ont une fonction de validation qui dépend d'une seule valeur S, et que la valeur actuelle S rend toutes les transactions dans le pool de mémoire valides, alors une seule transaction inversant la valeur de S pourrait rendre toutes les autres transactions dans le pool de mémoire invalides. Cela permet à un attaquant d'envoyer des transactions indésirables au pool de mémoire à un coût très faible, ce qui obstrue les ressources des nœuds du réseau.
Après des années d'efforts, visant à étendre les fonctionnalités tout en limitant les risques de 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 d'ERC-4337 consiste à diviser le traitement des opérations utilisateur en deux phases : validation et exécution. Toute la validation est d'abord traitée, puis toute l'exécution. Dans le pool de mémoire, une opération utilisateur n'est acceptée que si la phase de validation ne concerne que son propre compte et ne lit pas les variables d'environnement. Cela peut prévenir les attaques par échec multiple. De plus, des limites strictes en matière de gaz sont également imposées à l'étape de validation.
![Vitalik sur l'avenir possible d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
) Liens de recherche existants
) Le travail restant et les compromis
La principale question à résoudre actuellement est comment intégrer complètement l'abstraction de compte dans le protocole. Le compte abstrait via le protocole récemment populaire est 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 validation, et si le compte a configuré cette partie de code, ce code sera exécuté lors de l'étape de validation des transactions provenant de ce compte.
Le charme de cette méthode réside dans le fait qu'elle indique clairement les deux perspectives équivalentes de l'abstraction du compte local :
Si nous commençons par établir des limites strictes sur la complexité du code exécutable pendant la validation, alors la sécurité de cette approche est très claire : il suffit de remplacer la vérification ECDSA par une exécution de code EVM nécessitant un temps similaire.
Cependant, avec le temps, nous devons assouplir ces limites, car il est très important de permettre aux applications de protection de la vie privée de fonctionner sans relais, ainsi que d'assurer une résistance quantique. Pour cela, nous devons trouver des moyens plus flexibles de résoudre le risque de déni de service ###DoS(, sans exiger que les étapes de vérification doivent être extrêmement simplistes.
Le principal compromis semble être "écrire rapidement un plan 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 consisterait à écrire plus rapidement certains cas d'utilisation et à laisser plus de temps pour explorer d'autres cas d'utilisation. Une autre méthode serait de déployer d'abord une version d'abstraction de compte plus ambitieuse sur L2. Cependant, le défi auquel cela fait face est que l'équipe L2 doit avoir une confiance totale dans le travail d'adoption de la proposition pour être prête à la mettre en œuvre, en particulier pour s'assurer que L1 et/ou d'autres L2 pourront adopter des solutions compatibles à l'avenir.
Une autre application que nous devons clairement prendre en considération est le compte de stockage de clés, qui stocke l'état associé au compte sur L1 ou sur un L2 dédié, mais peut être utilisé sur L1 et tout L2 compatible. Pour y parvenir efficacement, il se peut que L2 doive prendre en charge des codes d'opération tels que L1SLOAD ou REMOTESTATICCALL, mais cela nécessite également que l'implémentation de l'abstraction des comptes sur L2 prenne en charge ces opérations.
) 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 mémoires tampons décentralisées, bien que la flexibilité soit légèrement plus grande pour la liste d'inclusion. De plus, la mise en œuvre de l'abstraction de compte devrait s'efforcer d'atteindre une coordination entre L1 et L2 autant que possible. Si nous prévoyons à l'avenir que la plupart des utilisateurs utiliseront des Rollup de stockage de clés, la conception de l'abstraction de compte devrait en tenir compte.
![Vitalik sur l'avenir possible d'Ethereum (6) : The Splurge]###https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
Amélioration EIP-1559
) Il résout quel problème ?
EIP-1559 a été activé sur Ethereum en 2021, améliorant considérablement le temps moyen d'inclusion des blocs. Cependant, l'implémentation actuelle d'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 elle est globalement plus concise. Cependant, EIP-1559 lui-même ainsi qu'EIP-4844 n'ont pas tenté de résoudre le deuxième problème. Par conséquent, la situation actuelle est un état intermédiaire chaotique, impliquant deux mécanismes différents, et il y a un point de vue selon lequel, avec le temps, les deux nécessiteront des améliorations.
De plus, 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 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 le pire des cas, c'est-à-dire que la consommation totale de gas d'un bloc occupe une ressource, mais l'utilisation moyenne réelle est bien inférieure à cela, ce qui entraîne de l'inefficacité.
![Vitalik sur l'avenir possible d'Ethereum (6) : The Splurge])https://img-cdn.gateio.im/webp-social/moments-fe95dd28b911aea1a22365468b7c42cd.webp(
) 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 de l'EIP-1.