En Ethereum, les ressources étaient jusqu'à récemment limitées et tarifées à l'aide d'une seule ressource appelée "gas". Le gas est une mesure de la quantité d'"effort de calcul" nécessaire pour traiter une transaction ou un bloc donné. Le gas regroupe plusieurs types d'"effort", notamment :
- Calcul brut (par exemple ADDITION, MULTIPLICATION)- Lecture et écriture dans le stockage d'Ethereum (par exemple SSTORE, SLOAD, transferts ETH)- Bande passante des données- Coût de génération d'un preuve ZK-SNARKdu blocPar exemple, cette transactionque j'ai envoyé a coûté un total de 47 085 d'essence. Cela est réparti entre (i) un coût de base de 21000 d'essence, (ii) 1556 d'essence pour les octets dans les données d'appel incluses dans la transaction (iii) 16500 d'essence pour la lecture et l'écriture dans le stockage, (iv) 2149 d'essence pour en fairejournal, et le reste pour l'exécution EVM. Les frais de transaction qu'un utilisateur doit payer sont proportionnels au gas consommé par la transaction. Un bloc peut contenir jusqu'à un maximum de 30 millions de gas, et les prix du gas sont constamment ajustés via le @vbuterin/eip-1559-faq">Mécanisme de ciblage EIP-1559, garantissant qu'en moyenne, les blocs contiennent 15 millions de gaz.
Cette approche a une efficacité majeure : parce que tout est fusionné en une ressource virtuelle, elle conduit à une conception de marché très simple. Optimiser une transaction pour minimiser les coûts est facile, optimiser un bloc pour collecter les frais les plus élevés possibles est relativement facile (à l'exceptionMEV) et il n'y a pas d'incitations étranges qui encouragent certaines transactions à se regrouper avec d'autres transactions pour économiser sur les frais.
Mais cette approche comporte également une inefficacité majeure : elle considère que les différentes ressources sont mutuellement convertibles, alors que les limites sous-jacentes réelles de ce que le réseau peut gérer ne le sont pas. Une façon de comprendre ce problème est d'examiner ce diagramme :
La limite de gaz impose une contrainte de
𝑥1∗𝑑𝑎𝑡𝑎+𝑥2∗𝑐𝑜𝑚𝑝𝑢𝑡𝑎𝑡𝑖𝑜𝑛- Les transactions qui consomment beaucoup d'une ressource sont encore inutilement facturées en grande quantité, même si toutes les autres transactions dans le bloc utilisent peu de cette ressource.- Il crée des incitations pour que les transactions lourdes en données et en calcul se regroupent en un seul paquet pour économiser des coûts.Je soutiendrais qu'une règle de style EIP-7623, à la fois pour les données d'appel de transaction et pour d'autres ressources, peut apporter des avantages suffisamment importants pour en valoir la peine malgré ces inconvénients. Cependant, si et quand nous sommes prêts à fournir l'effort de développement (nettement plus élevé), il existe une approche plus idéale.
Multidimensionnel EIP-1559: la stratégie plus difficile mais idéaleCommençons par rappeler comment fonctionne le EIP-1559 “classique”. Nous nous concentrerons sur la version introduite dans le EIP-4844 pour les blobs, car elle est mathématiquement plus élégante.
Nous suivons un paramètre, excess_blobs. Pendant chaque bloc, nous définissons :
excès_blobs EIP-1559 de retour en 2020. Avec l'EIP-4844, nous avons maintenant deux prix flottants séparés pour le gas et pour les blobs.
Frais de base de gaz sur une heure le 08-05-2024, en gwei. Source : ultrasound.money.
En principe, nous pourrions ajouter des frais supplémentaires de stockage en lecture, et d'autres types d'opérations indépendantes, bien que avec une réserve que je développerai dans la section suivante.
Pour les utilisateurs, l’expérience est remarquablement similaire à celle d’aujourd’hui : au lieu de payer un seul frais de base, vous en payez deux, mais votre portefeuille peut vous en faire abstraction et vous montrer simplement les frais attendus et les frais maximums que vous pouvez vous attendre à payer.
Pour les constructeurs de blocs, la plupart du temps, la stratégie optimale est la même qu'aujourd'hui : inclure tout ce qui est valide. La plupart des blocs ne sont pas pleins - nidans le gaznidans les blobsLe cas difficile est lorsque le gaz ou les blobs sont suffisants pour dépasser la limite de bloc, et que le constructeur doit potentiellement résoudre unProblème de sac à dos multidimensionnelpour maximiser son profit. Cependant, même s'il existe de très bons algorithmes d'approximation, les gains de la création d'algorithmes propriétaires pour optimiser les profits dans ce cas sont bien inférieurs aux gains obtenus en faisant de même avec MEV.
Pour les développeurs, le principal défi est la nécessité de repenser les fonctionnalités de l'EVM et de son infrastructure environnante, conçues autour d'un prix et d'une limite uniques aujourd'hui, en une conception qui prend en compte plusieurs prix et plusieurs limites. Un problème pour les développeurs d'applications est que l'optimisation devient légèrement plus difficile : dans certains cas, vous ne pouvez plus dire de manière non équivoque que A est plus efficace que B, car si A utilise plus de calldata mais que B utilise plus d'exécution, alors A pourrait être moins cher lorsque calldata est bon marché et plus cher lorsque calldata est cher. Cependant, les développeurs pourraient tout de même obtenir des résultats raisonnablement bons en optimisant en fonction des prix moyens historiques à long terme.
Tarification multidimensionnelle, l'EVM et les sous-appelsIl y a un problème qui n'est pas apparu avec les blobs, et n'apparaîtra pas avec EIP-7623 ou même une implémentation de tarification multidimensionnelle "complète" pour calldata, mais apparaîtra si nous essayons de tarifer séparément les accès à l'état, ou toute autre ressource: les limites de gaz dans les sous-appels.
Les limites de gaz dans l'EVM existent en deux endroits. Premièrement, chaque transaction définit une limite de gaz, qui limite le montant total de gaz pouvant être utilisé dans cette transaction. Deuxièmement, lorsqu'un contrat appelle un autre contrat, l'appel peut définir sa propre limite de gaz. Cela permet aux contrats d'appeler d'autres contrats en lesquels ils n'ont pas confiance, tout en garantissant qu'ils auront encore du gaz pour effectuer d'autres calculs après cet appel.
Une trace d'une transaction d'abstraction de compte, où un compte appelle un autre compte et ne donne au destinataire qu'une quantité limitée de gaz, pour s'assurer que l'appel externe puisse continuer à s'exécuter même si le destinataire consomme tout le gaz qui lui a été attribué.
Le défi est le suivant : rendre le gaz multidimensionnel entre différents types d'exécution semble nécessiter des sous-appels pour fournir plusieurs limites pour chaque type de gaz, ce qui nécessiterait un changement vraiment profond de l'EVM et ne serait pas compatible avec les applications existantes.
C'est une des raisons pour lesquelles les propositions de gaz multidimensionnel s'arrêtent souvent à deux dimensions : les données et l'exécution. Les données (qu'il s'agisse de l'appel de transaction ou des blocs) ne sont attribuées qu'en dehors de l'EVM, de sorte que rien à l'intérieur de l'EVM n'a besoin de changer pour que l'appel de transaction ou les blocs soient tarifés séparément.
Nous pouvons envisager une solution de style “EIP-7623” à ce problème. Voici une mise en œuvre simple : pendant l'exécution, facturer 4 fois plus pour les opérations de stockage ; pour simplifier l'analyse, disons 10000 gas par opération de stockage. À la fin de la transaction, rembourser min(7500 * opérations_de_stockage, gas_d_execution). Le résultat serait qu'après déduction du remboursement, un utilisateur est facturé :
execution_gas + 10000 *opérations de stockage - min(7500 *opérations de stockage, gas d'exécution)
Ce qui équivaut à :
max(execution_gas + 2500 opérations de stockage, 10000storage_operations)
Cela reflète la structure de l'EIP-7623. Une autre façon de le faire est de suivre les opérations de stockage et le gaz d'exécution en temps réel, et de facturer soit 2500, soit 10000 en fonction de la quantité maximale (gaz d'exécution + 2500)opérations de stockage, 10000Le coût en gaz des opérations de stockage) augmente au moment où l'opcode est appelé. Cela évite le besoin pour les transactions de sur-allouer du gaz qu'elles récupéreront principalement via des remboursements.
Nous n'obtenons pas d'autorisation détaillée pour les sous-appels : un sous-appel pourrait consommer toute l'"allocation" d'une transaction pour des opérations de stockage bon marché. Mais nous obtenons quelque chose de suffisamment bon, où un contrat effectuant un sous-appel peut définir une limite et s'assurer qu'une fois l'exécution du sous-appel terminée, l'appel principal a toujours suffisamment de gaz pour effectuer tout post-traitement nécessaire.
La solution de tarification la plus simple et complète que je puisse imaginer est la suivante : nous considérons les limites de gaz des sous-appels comme étant proportionnelles. C'est-à-dire, supposons qu'il y en ait
𝑘
différents types d'exécution, et chaque transaction définit une limite multidimensionnelle
𝐿1…𝐿𝑘
. Suppose that, at the current point in execution, the remaining gas is
𝑔1…𝑔𝑘
Supposons qu'un opcode CALL soit appelé, avec une limite de gas de sous-appel
𝑆
. Laissez
𝑠1=𝑆
, et ensuite
𝑠2=𝑠1𝑔1∗𝑔2
,
𝑠3=𝑠1𝑔1∗𝑔3
, et ainsi de suite.
C’est-à-dire que nous traitons le premier type de gaz (de manière réaliste, l’exécution de la machine virtuelle) comme étant une sorte d'« unité de compte » privilégiée, puis nous affectons les autres types de gaz afin que le sous-appel obtienne le même pourcentage de gaz disponible pour chaque type. C’est un peu moche, mais cela maximise la rétrocompatibilité. Si nous voulons rendre le schéma plus « neutre » entre les différents types de gaz, au prix de sacrifier la rétrocompatibilité, nous pourrions simplement faire en sorte que le paramètre limite de gaz sous-call représente une fraction (par exemple. [1… 63] / 64) du gaz restant dans le contexte actuel).
Dans l'un ou l'autre cas, il convient cependant de souligner que dès que vous commencez à introduire un gaz d'exécution multidimensionnel, le niveau inhérent de la laideur augmente, et il semble difficile d'éviter cela. Ainsi, notre tâche est de faire un compromis compliqué : acceptons-nous une certaine laideur au niveau de l'EVM, afin de débloquer en toute sécurité des gains significatifs de scalabilité L1, et si c'est le cas, quelle proposition spécifique fonctionne le mieux pour l'économie du protocole et les développeurs d'applications ? Il est fort probable que ce ne soit ni l'un ni l'autre des propositions que j'ai mentionnées ci-dessus, et il reste encore de la place pour trouver quelque chose de plus élégant et de meilleur.
Avertissement：- Cet article est repris de [[Vitalik Buterin]], Tous les droits d'auteur appartiennent à l'auteur originalVitalik Buterin]. Si vous avez des objections à cette réimpression, veuillez contacter le [Gate Learn](https://www.Gate.com/questionnaire/3967l'équipe, et ils s'en occuperont rapidement.- Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.- Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdite.
