jakiro
Auteur: Vitalik, fondateur d’Ethereum;
Dans Ethereum, jusqu’à récemment, les ressources sont limitées et un seul prix de ressources appelé « gaz » est utilisé.Le gaz est la quantité de «calcul» requis pour une transaction ou un bloc donné.Le gaz intègre divers types d ‘«effort».
-
Calcul d’origine (comme ajouter, multiplier)
-
Lisez et écrivez à Ethereum Storage (comme SSTORE, Sloadeth Transfer)
-
Bande passante de données
-
Le coût de la génération de ZK-Snark pour générer des blocs
Par exemple, la transaction que j’ai envoyée (https://etherscan.io/tx/0xc5195b64cc333b8098d71fbd032e05d4545917e3be8d123ab06e1ad7998e))))> « >Un total de 47 085 gaz dépensé.Il s’agit d’un «coût de base» divisé en (i) 21000 gaz.Les frais de transaction que les utilisateurs doivent payer sont directement proportionnels au gaz consommé par la transaction.> « >Un bloc peut contenir jusqu’à 30 millions de gaz, et le prix du gaz est ajusté en permanence via le mécanisme cible EIP-1559 pour garantir que le bloc contient une moyenne de 15 millions de gaz.
Cette méthode a une efficacité principale: parce que tout est fusionné dans une ressource virtuelle, il conduit à une conception de marché très simple.Les transactions optimisées sont faciles à minimiser les coûts.
mais> « >Il existe également un problème majeur inefficace dans cette méthode: il considère différentes ressources comme une conversion mutuelle, mais la limite de potentiel réelle que le réseau peut gérer n’est pas le cas.Une façon de comprendre ce problème est de voir cette image:
LIMITES DE GAS Les contraintes suivantes: X1 * Données + x2 * Calcul & lt;Les contraintes de sécurité sous-jacentes réelles sont généralement plus proches des données max (x1 *, calcul x2 *) & lt;Cette différence fait que le gaz restreint l’exclusion inutile des blocs de sécurité réels, ou accepte les blocs réels dangereux, ou un certain mélange des deux.
S’il y a une ressource avec différentes restrictions de sécurité, le gaz à une dimension unique peut réduire le débit d’un seul facteur?Par conséquent, les gens sont longtemps intéressés par le concept de gaz multidimensionnel depuis longtemps.Cet article traite des avantages de cette méthode et des perspectives d’améliorer encore cette méthode.
Blobs: gaz multidimensionnel à Dencun
Plus tôt cette année, la taille moyenne du bloc d’Ethereum était de 150 Ko.Une grande partie de cette taille est les données de roulement: pour des raisons de sécurité, le protocole de 2e couche stocke les données sur la chaîne.Ces données sont très coûteuses: bien que le coût des transactions ROLUP soit environ 5 à 10 fois inférieur aux transactions correspondantes sur Ethereum L1, ce coût est encore trop élevé pour de nombreux cas.
Pourquoi ne pas réduire le coût de Calldata (actuellement 16 gaz par octet non-nombre et 4 gaz par nombre d’octets), de sorte que ce rollup est moins cher?Nous l’avons déjà fait et nous pouvons le refaire.La réponse ici est: la taille du bloc dans le pire des cas est 300 000/16 = 1875000 octets non nombre, et le réseau est presque impossible à gérer le bloc de cette taille.Si le coût est réduit de 4 fois, la capacité maximale sera augmentée à 7,5 Mo, ce qui entraînera d’énormes risques de sécurité.
Ce problème est finalement résolu en introduisant un espace de données distinct (appelé « blob ») en introduisant un espace de données ROLUP facile séparé dans chaque bloc.Ces deux ressources ont des prix différents et des restrictions différentes: après le Dencun Hard Fork, un bloc Ethereum peut inclure un maximum de (i) 30 millions de gaz et (ii) 6 blob.Les deux ressources ont un prix distinct.
En conséquence, le coût des rouleaux a été réduit de 100 fois, et le volume des transactions sur les rouleaux a augmenté de plus de 3 fois, et la taille du bloc maximale théorique n’a fait que légèrement augmenter: d’environ 1,9 Mo à environ 2,6 Mo.
Les frais de trading Rollup sont fournis par GrowthEpie.xyz.Dencun Fork a eu lieu le 13 mars 2024 et a introduit un blob de prix multidimensionnel.
Client de gaz et d’apatrides multidimensionnel
Dans un avenir proche, des problèmes similaires avec des certificats de stockage sans client sans état se produiront également.Un client apatride est un nouveau type de client qui peut vérifier la blockchain sans avoir à stocker beaucoup ou des données localement.Le client sans état implémente cela en acceptant la preuve de la partie spécifique de Ethereum de la transaction dans le bloc.
Un client sans état reçoit un bloc et prouve la preuve de la valeur actuelle de la partie spécifique de l’état (tel que le solde du compte, le code, le stockage) impliquée dans l’exécution de l’exécution du bloc.Cela permet aux nœuds de vérifier le bloc sans aucun stockage lui-même.
Il faut 2100 à 2600 gaz pour stocker la lecture à la fois, selon le type de lecture, et le coût d’écriture de stockage est plus élevé.En moyenne, un bloc exécutera environ 1 000 stockage et lecture (y compris le chèque de solde ETH, la ralentissement de l’appel SSTORE, la lecture du code contractuel et d’autres opérations).Cependant, la valeur maximale théorique est de 30000000/2100 = 14285 lecture.La charge de bande passante d’un client sans état est proportionnelle au nombre.
Aujourd’hui, le plan est transféré de l’arbre Merkle Patricia à l’arbre Verkle en concevant l’arbre d’État d’Ethereum pour soutenir le client apatride.Cependant, l’arbre Verkle n’a pas de résistance quantique, et ce n’est pas le meilleur choix pour le système à preuves Stark mis à jour.Par conséquent, de nombreuses personnes sont intéressées à soutenir un client sans état via l’arbre Dual Merkle et à sauter complètement Verkle, soit après les transitions de Verkle pendant quelques années, une fois que le Stark deviendra plus mature, il sera mis à niveau.
L’arbre de hachage binaire a beaucoup d’avantages, mais ils ont une faiblesse clé qu’il faut beaucoup de temps à générer: bien que l’arbre Verkle puisse prouver que plus de 100 000 valeur par seconde, le Stark basé sur le hachage est généralement seulement Seul le Stark basé sur le hachage est généralement seulement seulement il peut prouver des milliers de hachage par seconde, prouve que chaque valeur nécessite une « branche » contenant de nombreuses valeurs de hachage.
Étant donné que, à partir du système de certification super optimisé (comme Binius et Plonky3) et le hachage spécial (comme Vision-Mark-32), nous sommes probablement dans une période de temps en moins d’une seconde. N’est pas 14 285.Chaque bloc n’est pas un problème, mais le pire des cas (peut être publié par un attaquant) détruira le réseau.
La méthode « par défaut » que nous traitons de cette situation est de ré-évaluer: rendre le stockage à lire plus cher, afin de réduire la valeur maximale de chaque bloc à un niveau plus sûr.Cependant, nous l’avons fait plusieurs fois.> « >Une meilleure méthode est le gaz multidimensionnel: les restrictions et les charges d’accès au stockage, respectivement, conservent l’utilisation moyenne de 1 000 accès de stockage à chaque bloc, mais fixez la limite de chaque bloc à 2000 fois.
Gaz multidimensionnel plus commun
Une autre ressource à considérer est la croissance de l’État: augmenter le fonctionnement de l’état Ethereum, et le nœud entier devra détenir un état complet.Le caractère unique de la croissance de l’État est que la raison de la restriction de la croissance de l’État est exactement une utilisation continue à long terme, et non un pic.Par conséquent, l’ajout d’une dimension de gaz séparée pour l’augmentation de l’opération d’augmentation de l’échelle d’état (par exemple, de zéro à la création de contrat non zéro) peut être précieuse, mais l’objectif est différent: nous pouvons fixer le prix flottant pour une utilisation moyenne spécifique , mais il n’est pas du tout défini.
Cela montre l’une des caractéristiques puissantes du gaz multi-vitamine: il nous permet de poser les questions suivantes: (> « >i) Quelle est l’utilisation moyenne idéale de chaque ressource et l’utilisation maximale de sécurité de (ii) chaque bloc.Nous ne fixons pas le prix du gaz en fonction de la valeur maximale de chaque bloc, mais de l’utilisation moyenne.
Des cas plus compliqués, tels que certaines considérations de sécurité accumulées de deux ressources, peuvent être traitées en faisant en sorte que le code d’exploitation ou le coût de ressources coûte un certain nombre de gaz (par exemple, de zéro à la SSTORE non zéro peut coûter 5 000 gaz de la preuve du client sans état et 20000 gaz de stockage).
La valeur maximale de chaque transaction: le moyen plus faible mais plus simple d’obtenir le gaz multidimensionnel
Soit x1 le coût des données, et x2 est le coût de gaz calculé.
Dans le nouveau plan, nous définissons le coût du gaz de la transaction comme: Gas = max (x1 * données, calcul x2 *)
En d’autres termes, la transaction n’est pas facturée en fonction du calcul de Data Plus, mais est facturée davantage en fonction des ressources des deux ressources qu’elle consomment.Cela peut facilement se développer pour couvrir plus de dimensions (par exemple max (…, x3 * Storage_Access)).
Il devrait être facile de voir comment cela augmente le débit tout en assurant la sécurité.La quantité maximale de données dans un bloc est toujours Gaslimit / X1, qui est exactement la même que la solution de gaz à une dimension.De la même manière, la quantité de calcul maximale théorique est Gaslimi / X2, qui est exactement la même que la solution de gaz à une dimension à nouveau.Cependant, le coût de toutes les données consommées et des transactions calculées sera réduite.
Il s’agit du schéma proposé dans l’EIP-7623 proposé pour réduire la taille maximale du bloc et augmenter davantage le nombre de BLOB.Le mécanisme précis de l’EIP-7623 est légèrement plus compliqué: il maintient le prix CallData actuel de 16 gaz, mais ajoute le « prix de réserve » de 48 gaz par octet;Par conséquent, EIP-7623 réduit les données d’appel de transaction maximales dans le bloc d’environ 1,9 Mo à environ 0,6 Mo, tout en conservant le coût de la plupart des applications inchangées.L’avantage de cette méthode est qu’il a très peu changé par rapport à la solution de gaz de dimension actuelle, il est donc très facile à réaliser.
Il a deux inconvénients:
1. Même si toutes les autres transactions du bloc utilisent seulement une très petite ressource, un grand nombre de transactions qui occupent une ressource n’auront toujours pas besoin de facturer beaucoup de frais.
2. Il inspire les transactions denses à forte intensité de données et calculées à un package pour réduire les coûts.
À mon avis, les règles du style EIP-7623 peuvent apporter suffisamment d’avantages aux données d’appel de transaction ou d’autres ressources, même s’il y a ces lacunes, cela en vaut la peine.Cependant, si nous sommes prêts à investir (significatifs et plus élevés), il existe une méthode plus idéale.
EIP-1559 multidimensionnel: stratégie plus difficile mais idéale
Prenons d’abord le principe de travail de l’EIP-1559 « conventionnel ».Nous nous concentrerons sur la version introduite par BLOB dans EIP-4844 car elle est plus élégante en mathématiques.
Nous suivons un paramètre, excès_blobs.Pendant chaque période, nous nous sommes installés:
Excès_blobs & lt; – max (excès_blobs + len (block.blobs) -target, 0)
Ici cible = 3.En d’autres termes, si le nombre de blocs d’un bloc est plus que la cible, les excès augmentent, et si le nombre de blocs dans le bloc est inférieur à la cible, il diminuera.Ensuite, nous avons configuré BLOB_BASEFEE = EXP (excès_blobs / 25.47), où Exp est une valeur approximative Exp (x) de la fonction d’index.
En d’autres termes, chaque fois que Excès_Blobs augmente d’environ 25 fois, le coût de base du blob augmentera d’environ 2,7 fois.Si le blob devient trop cher, l’utilisation moyenne diminuera, puis l’excès de_blobs commence à diminuer, réduit ainsi automatiquement le prix.Le prix de Blob est constamment ajusté pour garantir que le bloc est à moitié complet – c’est-à-dire que chaque bloc contient une moyenne de 3 blobs.
Si le montant de l’utilisation apparaît à court terme, il y aura des restrictions: chaque bloc ne peut contenir que jusqu’à 6 blob.Cependant, dans des circonstances normales, chaque blob n’a besoin que de payer BLOB_BASEFEE et d’ajouter un petit frais de priorité supplémentaire comme inspiration.
Ce prix du gaz est dans Ethereum depuis de nombreuses années: dès 2020, l’EIP-1559 a introduit un mécanisme très similaire.Grâce à l’EIP-4844, nous avons maintenant deux prix flottants de gaz et de gouttes séparés.
Le coût de base du gaz dans une heure le 8 mai 2024, l’unité est GWEI.Source: ultrasonic.money
En principe, nous pouvons ajouter plus de coûts en solo à la lecture de stockage et à d’autres types d’opérations, mais il y a un avertissement que je l’expliquerai en détail dans la section suivante.
Pour les utilisateurs, cette expérience est très similaire à aujourd’hui: vous ne payez plus de frais de base, mais payez deux frais de base, mais votre portefeuille peut vous résoudre, vous montrez seulement que vous pouvez vous attendre à ce que vous vous attendiez à des dépenses attendues et aux dépenses maximales .
Pour les constructeurs de blocs, la plupart du temps, la meilleure stratégie est la même qu’aujourd’hui: y compris tout contenu efficace.La plupart des blocs ne sont pas complets – que ce soit du gaz ou du blob.Une situation difficile est que lorsqu’il y a suffisamment de gaz ou suffisamment de blobs pour dépasser les restrictions de blocs, le constructeur doit potentiellement résoudre le problème de sac à dos multidimensionnel pour maximiser ses bénéfices.Cependant, même s’il y a un assez bon algorithme d’approximation, dans ce cas, les avantages obtenus en optimisant le profit en formulant l’algorithme propriétaire sont beaucoup plus petits que l’utilisation de MEV pour la même opération.
Pour les développeurs, le principal défi est de repenser les fonctions de l’EVM et de son infrastructure périphérique.Un problème rencontré par les développeurs d’applications est que l’optimisation devient légèrement difficile: dans certains cas, vous ne pouvez plus dire clairement que A est plus efficace que B, car si A utilise plus CallData et B est utilisé plus d’exécution, alors plus d’exécution, alors alors Lorsque CallData est bon marché, il est plus cher lorsque Calldata coûte cher.Cependant, les développeurs peuvent toujours obtenir de très bons résultats en optimisant le prix moyen historique à long terme.
Prix multidimensionnelle, EVM et sous-appels (sous-appels)
Un problème n’apparaîtra pas dans BLOB, ni dans l’EIP-7623, ni même dans l’implémentation de prix multidimensionnelle « complète » de CallData, mais si nous essayons de tariser le statut ou toute autre ressource, nous essayons de tariser le statut ou Toute autre ressource.
Le gaz dans EVM est limité à deux endroits.Tout d’abord, chaque transaction est établie avec une limite de gaz, ce qui limite la quantité totale de gaz qui peut être utilisée dans la transaction.Deuxièmement, lorsqu’un contrat appelle un autre contrat, l’appel peut fixer sa propre limite de gaz.Cela permet au contrat d’appeler d’autres contrats auxquels ils ne font pas confiance et de garantir qu’ils ont toujours le gaz restant après avoir appelé pour effectuer d’autres calculs.
La trace de la transaction abstraite du compte, l’un des comptes appelle l’autre compte et ne fournit que l’appelant un nombre limité de gaz pour s’assurer que même si l’appel consomme tout le gaz qui lui est attribué, l’appel externe peut continuer à fonctionner .
Le défi est: le gaz devient multidimensionnel entre les différents types d’exécution.
C’est l’une des raisons pour lesquelles la proposition de gaz multidimensionnelle reste généralement en deux dimensions: les données et l’exécution.Les données (que le trading soit calldata ou blob) ne se répand qu’à l’extérieur de l’EVM, il n’est donc pas nécessaire de modifier le contenu à l’intérieur de l’EVM pour rendre le CallData ou Blob au prix séparément.
Nous pouvons trouver une « solution EIP-7623 » pour résoudre ce problème.Il s’agit d’une simple mise en œuvre: lors de la mise en œuvre, le coût de la charge de l’opération de stockage est 4 fois; afin de simplifier l’analyse, nous supposons que chaque opération de stockage est de 10 000 gaz.À la fin de la transaction, le remboursement MIN (7500 * Storage_Operations, Execution_Gas).En conséquence, après déduction du remboursement, l’utilisateur doit payer les dépenses suivantes:
EXECUMENT_GAS + 10000 * Storage_Operations -Min (7500 * Storage_Operations, Execution_Gas)
Ceci est égal à:
Max (exécution_gas + 2500 * Storage_Operations, 10000 * Storage_Operations)
Cela reflète la structure de l’EIP-7623.Une autre méthode consiste à suivre le Storage_Operations et Execution_Gas en temps réel, et la quantité de 2500 ou 10000 gaz est facturée par le MAX (EXECUMENT_GAS + 2500 * Storage_Operations, 10000 * Storage_Operations) en fonction du code d’opération d’appel.Cela évite la transaction qui nécessite une allocation excessive du gaz ciel, et ces Gass sont principalement récupérés par des remboursements.
Nous n’avons pas obtenu de licence à grain fin pour les sous-appels: les sous-appels peuvent consommer toutes les « allocations » des transactions pour les opérations de stockage bon marché.Mais nous obtenons suffisamment de bonnes choses.
La plus simple « solution de prix multidimensionnelle complète » à laquelle je peux penser est: nous considérons le sous-appel de l’enfant qui appelle le gaz en proportion.En d’autres termes, en supposant
? Différents types d’exécution, chaque transaction définit une limite multidimensionnelle?En supposant le point d’exécution actuel, le gaz restant
Pour?En supposant que les appels appellent un code d’exploitation avec une limite de gaz sous-contexte S.Soit S1 = S, puis S2 = S1 / G1 * G2, S3 = S1 / G1 * G3, etc.
En d’autres termes, nous considérons le premier type de gaz (en fait, l’exécution d’une machine virtuelle) comme un privilège «unité de compte», puis attribuent d’autres types de gaz afin que l’enfant puisse être appelé dans chaque type.C’est un peu moche, mais cela maximise la compatibilité arrière.Si nous voulons que le schéma soit plus « neutre » entre différents types de gaz, au prix de sacrifier le retard, nous pouvons simplement laisser l’enfant appeler le paramètre de limite de gaz représente une petite partie du gaz restant (par exemple [1 .. .
> « >Cependant, en tout cas, il convient de souligner qu’une fois que l’introduction de l’exécution multidimensionnelle du gaz, la laideur inhérente augmentera, ce qui semble difficile à éviter.
Par conséquent, notre tâche consiste à faire un complexe complexe – si nous acceptons certaines des choses laides au niveau EVM, afin de libérer en toute sécurité le revenu d’évolutivité L1 en toute sécurité.
Il est probable que ce ne soit personne que j’ai mentionné ci-dessus, et il y a encore de la place pour des choses plus élégantes et meilleures.
Merci pour les commentaires et l’examen d’Ansgar Dietrichs, de Barnabe Monoton et Davide Crapis.
